大多数成熟的项目都平行的维护多个发布线。例如，1.0.0发布后，该发布线会继续微小发布1.0.1，1.0.2等等，直到项目明确的决定终止这条线。请注意，仅仅因为发布了1.1.0不足以终止1.0.x线。例如，一些用户会制定某类政策，永远不升级到较新的次要或主要版本的第一个发布—他们希望其他人能将bug试验出来，例如1.1.0，那么就等待1.1.1。这不一定是自私（请牢记，他们也放弃了bug修正和新特性）；仅仅是出于某些原因，他们必须在升级上非常小心。因此，假设项目在发布1.1.0之前发现1.0.3中有一个重大bug，如果只是将bug修正纳入到1.1.0，而告知所有的1.0.x用户必须升级到1.1.0，其结果将会非常恶劣。为什么不同时发布1.1.0和1.0.4，这样大家都能高兴吧？
待1.1.x线圆满后，你可以宣布1.0.x进入了生命结束（end of life，EOL）。这一步必须正式宣告。宣告可以是独立的，也可以作为1.1.x发布宣告的一部分；可是这样做时，用户必须能够知道老的开发线正在被关闭，这样他们可以根据情况决定是否升级。
一些项目设置了保证对于前一发布线作出支持的窗口时间。在开源环境中，“支持”意味着接受针对该线的bug报告，并在发现重大bug后发布维护版本。另外一些项目并没有给出预定义的时间，而是根据报告的bug数量判断还在使用较旧发布线的用户。当低于某个百分比时，就可以宣布发布线的结束并停止对它的支持。
对于每个发布，请确保在bug跟踪系统中有目标版本或目标里程碑，这样人们可以根据正确的发布填写bug。当然也不要忘记为最新的开发源代码提供叫做“开发”或“最新”的目标，因为总有些人—不仅仅是活跃的开发者—通常会在官方发布的最前沿。
对于安全bug的处理请参考Chapter 6, 交流the section called “声明安全漏洞”，但是对于安全发布有许多特殊的细节需要讨论。
一个安全发布是一个专门关闭安全漏洞的发布。修正bug的代码在发布之前不能公布于众，也就是说在发布日之前代码不能提交到版本库，也意味着在公开之前代码不能经过公共测试。很明显，开发者可以自己检查这个修正，并在私下里测试发布，但是无法进行广泛的真实世界测试。
因为缺乏测试，所以安全发布必须是在现有发布基础之上，只附加了安全bug的修正，没有其他变更的发布。这是因为未经测试的变更越多，越有可能导致新的bug，甚至是新的安全bug！这种保守也是对管理员的一种友好，他们将要部署安全修正，但是他们的部署策略倾向于不在同一时间部署任何其他变更。
作出安全发布有时有些小的诡计。例如，项目可能工作于发布1.1.3，对于1.1.2的一些bug修正已经公开声明，此时出现了安全报告。很自然，开发者在完成修正前不能讨论安全问题，他们必须继续讨论，好像1.1.3还会按照计划推出一样。但是当1.1.3实际上到来时，与1.1.2的区别只有安全补丁，而所有其他的修正都会进入1.1.4（当然，现在也会包含安全修正，以后所有的版本也会一直包含）。
你也可以为现有的版本号码添加一个额外的部分，以说明它只包含安全变更。例如，人们能够知道1.1.2.1是针对1.1.2的一个安全发布，所有更高的发布（1.1.3，1.2.0等）会包含相同的安全修正。对于了解内情的人，这个系统可以传递许多信息。在另一方面，那些不能紧跟项目的人，当大多数时间看到的是3部分的发布号码，偶尔看到4部分的号码会感到混乱。我见过的大多数项目会选择一致性，使用常规的下个号码作为安全发布，即使它意味着计划中的发布前进一个版本。