一旦源代码tarball已经从稳定的发布分支产生，发布过程公共部分便已经开始。但是在tarball进入公开之前，必须经过少量开发者的确认，通常需要三位或者更多。确认不仅仅是检测发布的明显缺陷；理想情况下，开发者应该下载tarball，在干净的系统上构建并安装，运行回归测试包Chapter 8, 管理志愿者的（见the section called “自动测试”），然后执行一些手工测试。假如通过了这些检查以及项目的其他的发布检查列表条件，开发者可能需要使用GnuPG（http://www.gnupg.org/）、PGP（http://www.pgpi.org/）或其他可以产生PGP兼容签名的程序为tarball作出数字签名。
大多数项目中，开发者仅仅使用个人的数字签名，而不是许多开发者（有一小部分，担不是大多数）希望使用的项目共享密钥。签名的开发者越多，经过的测试也就越多，一个关心安全的用户也就越可能找到一个到达该tarball的数字信任路径。
一经确认，发布版本（所有的tarballs、zip文件以及其他需要分发的格式）就应当放置到项目的下载区，并伴有数字签名，以及MD5/SHA1校验（seehttp://en.wikipedia.org/wiki/Cryptographic_hash_function）。有许多做这些工作的标准。一种方法是为每个发布包提供一个对应的数字签名，以及一个校验文件。例如，如果发布包是scanley-2.5.0.tar.gz，在同一目录的scanley-2.5.0.tar.gz.asc包含了这个tarball的数字签名，另一个文件scanley-2.5.0.tar.gz.md5则包含了MD5校验，也可以有另外一个scanley-2.5.0.tar.gz.sha1文件，包含SHA1校验。另一种方法是收集所有发布包的签名到一个单独的文件scanley-2.5.0.sigs；校验文件与之类似。
具体怎样做并不重要。只要保持简单的模式，描述清楚，并在每次发布保持一致即可。所有签名和校验的目的是为了用户校验自己的拷贝未经恶意修改。用户会在自己的电脑上运行这些代码—所以如果代码被篡改，攻击者可以立刻拥有到达所有数据的后门。本章后面的the section called “安全发布”有更详细的介绍。
对于包含许多变更的发布版本，许多项目会首先推出发布候选，例如scanley-2.5.0之前的scanley-2.5.0-beta1。候选的目的让代码在发布之前接受更广泛的测试。如果发现了问题，可以在发布分支修正，并推出新的发布候选（scanley-2.5.0-beta2）。这个周期会持续到不能发现不可接受的bug为止，最后的发布候选成为正式发布版本—也就是说最后的候选发布和正式发布的唯一区别只是版本号码的修饰词。
在大多数其他方面，候选发布一定要与正式发布保持相同的待遇。alpha、beta或rc修饰足以警告保守的用户等待真正的发布，而候选发布的声明邮件也必须指出他们的目的是征求反馈。除此以外，应该对候选发布提供与正式发布相同的关注。毕竟，你希望人们使用候选版本，因为暴露是发现bug的最佳方法，而且也因为你永远无法获知哪个候选会最终成为正式版本。
宣告发布很像宣布其他事件，一定要采用在Chapter 6, 交流的the section called “公开性”中描述的程序。当然，对于发布要额外注意一些事情。
每当你提供下载发布tarball的URL时，一定要确保给出MD5/SHA校验和数字签名文件的链接。因为宣告会出现在许多论坛里（邮件列表，新闻页等），这意味着人们会从许多地方获取到校验信息，这可以给关心安全的用户额外的保证，证明了校验本身没有被篡改。反复提供数字签名的链接并不会使其更安全，但是会让人们（尤其是与项目比较疏远的人）感受到项目对于安全的重视。
在宣告邮件和新闻页中，不应该仅仅报告关于发布的宣传信息，而应该包含CHANGES文件中相关的部分，这样人们就能够看到自己是否有兴趣去升级。这对于发布候选和最终发布同样重要；bug修正的出现和新特性的引入会吸引人们尝试候选版本。
最后，不要忘记感谢项目团队、测试人员以及所有花时间发起bug报告的人。不要单独提出某人的名字，除非某人承担了大量的工作，其价值被项目的每个人所认可。小心坐上信用贬值的索道（见Chapter 8, 管理志愿者的the section called “荣誉”）。