我一直在努力使用版本软件一段时间。 我不是在谈论命名约定，我在谈论如何在构建系统中实际应用版本直到发布。
我一般使用major.minor.maintenance- [发布类型] 即1.0.2-rc1
问题在于管理版本号。我尝试了很多方法（将它粘贴在构建文件，属性文件，数据库等等）但我没有发现任何真正有效的方法。
我想出的最接近的是使用Jira，我在这里记录： http://blog.sysbliss.com/uncategorized/release-management-with-atlassian-bamboo-and-jira.html
我想知道是否有人对此有任何好的想法。 此外，想知道人们如何处理发布版本....即如果我发布/部署版本1.0.0-rc1执行此版本中发现的错误然后登录到1.0.0（下一个/生产版本）。
答案 0 :(得分：4)
Microsoft使用<major>.<minor>.<patch>-<build number>（或变体）。
我喜欢使用<major>.<minor>.<buildnumber>
答案 1 :(得分：2)
在我工作的地方，我们使用Maven系统：artifact [-major-minor-revision] [ - SNAPSHOT]，它允许我们开发“进行中”版本，在瞬间通知（SNAPSHOT）和那些有已正式发布。一些例子是：
电子邮件服务-1.0.0-SNAPSHOT.jar
如果它中有SNAPSHOT，那么它还没有通过全套测试，或只是一个开发人员实验。如果它没有SNAPSHOT那么它就是候选版本。我们维护一个候选版本的存储库，一旦测试人员满意，就会发送最新版本。
所有这些都可以通过Maven下的构建文件中的一些简单条目来管理。见Maven2 tutorial
答案 2 :(得分：2)
现在这可能是一个死寂的帖子，但无论如何我还要加两分钱。我认为构建数字应该对每个看到它的人都有意义。所以我个人认为这是命名版本的好方法：
major.minor.patch.revision - 例如1.1.4.2342
主要/次要数字非常明显。但从第三个数字的角度来看，它仍然需要对客户意味着什么。我已将这个新版本发布给你，顾客先生，但由于我们修正了一些错误，因此不值得一个新的次要编号。所以我们增加了补丁号码。
第四个数字通常对客户来说绝对没有意义，因此您可能会对您和您公司中看到它的任何其他人有用。所以对我们来说，这个数字是SVN修订号。它告诉我们究竟哪个版本负责该版本，以便我们可以随时将其拉出来重新创建它。分支代码显然也实现了这一点，但并非100％确定。
此外，全数字版本号的另一个优点是它可以轻松集成到几乎所有连续构建系统中。
无论如何，这是我的两分钱。
答案 3 :(得分：1)
+1。关于构建的唯一附加信息（包括我的目的）是Subversion版本，尽管标记操作是我想要的80％。
手动维护发布/版本信息是一种巨大的痛苦。让JIRA驾驶它是一个好主意。
关于最后一个问题，关于错误/缺陷的记录位置和releasing版本：
通过JIRA管理这个的美妙之处在于，添加版本，生成更改日志等等都是自动化的。
答案 4 :(得分：0)
我们也使用<major>.<minor>.<buildnumber>，我们在构建服务器上使用CruiseControl /（。Net）进行管理。并使用Wix和CruiseControl Config来管理主要次要编号 - 仍然手动递增 - 但是在构建服务器上时会自动生成编号。您可以自动设置一个规则，即主要/次要增量 - 我们只是想手动执行此操作，以便在需要命名特定版本级别时由开发人员进行有意识的思考。
答案 5 :(得分：0)
Major.Minor.BuildDateNumber.DailyBuildNumber
主要和次要由我们设定，我们认为合适时手动递增它们。
BuildDateNumber是项目开始后的月数乘以100加上当月的日期数。
DailyBuildNumber在每天午夜后的每个版本中递增，从零开始。
E.g。 7月10日发布的第4版第5.2版，该项目于当年1月1日开始，版本号为
5.2.710.3
这是Version task in Nant为我们计算的。
这使版本号保持唯一，并且还允许我们快速计算安装的构建时间。