我开发了一个名为nearforums（http://nearforums.codeplex.com/）的开源论坛引擎，我想知道如何命名这些版本。
到目前为止，这些版本被命名为release1，release2等，但在接下来的几天里我将发布一个新版本，我不知道是否遵循发布N命名是个好主意......
我应该遵循mayor.minor版本风格吗？如何选择第一个“mayor.minor”和当前？如何处理错误修复+发布？
每次开发很少的“大”功能时，我都会继续发布。
感谢您的建议！
答案 0 :(得分：3)
询问5位开发人员，您可能会获得6种不同的版本编号建议。
无论您选择哪种版本号系统，都应确保遵循某些准则。大多数软件包管理系统都希望能够确定哪个是最新版本，因此您应该确保您的版本号系统始终增加，第一个数字具有最高优先级，第二个数字具有最高版本等等。例如，如果您现在，如果您决定使用XY系统，则不应该回归到版本1.4，至少应该从3.1或4.0开始。大多数软件包管理系统都有一个时代概念来修复这样的案例，其中版本号会退化，但你不应该依赖它。
一般情况下，您的版本号应由虚线数字组成，每个数字按数字顺序增加（因此，1,2,3，...，9,10,11 ......，而不是按字典顺序排序的1 ，10,11,2,3，......）。
有些人喜欢使用major.minor.patch系统，其中主要数字为向后不兼容的更改或主要新功能递增，次要数字增量用于向后兼容的更改或次要新功能，并且修补程序仅更改用于向后兼容的错误修正，不引入任何新功能。
其他人喜欢使用类似Ubuntu的系统，使用year.month或year.release（可能还有第三个数字以及补丁或错误修正，或year.month.day）。这可以帮助避免必须决定什么构成“主要”特征，并且可以给人们比任意“7”或“23”更难忘的数字。这样做的缺点是，当您进行向后不兼容的更改时，不要让您的用户知道，尽管取决于您正在做什么，可能不太相关（如果您始终保持向后兼容性，或者您正在编写类似Linux的内容）分布包含很多部分，其中一些可能是向后兼容的，而其中一些可能不兼容，保证版本之间的向后兼容性并没有多大意义。）
如果您觉得可以提出强烈的向后兼容性概念，我建议您按照Semantic Versioning中给出的指南使用major.minor.patch系统。在这些准则中，您将增加主要版本以进行向后不兼容的更改。您可以为次要版本增加可能仍然添加新功能的向后兼容更改（因此有些人可能依赖于大于2.3.0的版本，因为这是添加新功能的版本，但是小于3.0.0，因为可能有不相容的变化）。您只为错误修正增加该修补程序级别。如果您现在正在使用第3版，我将在4.0.0开始您的下一个版本，然后从现在开始使用此模型。
如果您不想进行工作以确保兼容性并确定哪些是向后兼容的，那么只需使用year.month，year.month.version或year.version，其中版本递增该月份或年份内的每个版本均为1（取决于您的发布频率）。因此，您的下一个版本将类似于2010.1,2010.8.1或2010.8，具体取决于确切的形式（或者您可以使用10.1,10.8.1等）。
（嗯。我只是一个开发者，我想我现在至少给了你6个选择。哦，好吧，希望其中一个适合你）