您如何对项目进行版本管理并管理版本？

Question

我们的情况如下，但我对任何情况下的这个问题都很好奇。

我们有一个由4个项目组成的框架：

• 豆
• util的
• 框架
• 网络

我们还有需要版本的模块，并且依赖于bean和util的版本。

最后，我们有一个客户项目，其中包含特定版本的核心项目和一个或多个模块。

是否有标准的方式来版本化这些项目？

对我来说，简单的事情变得非常复杂，因为我们尝试向QA提供版本，然后通过维护版本（release = tag和可能的分支）来管理我们的持续开发。

我更喜欢以下内容：

1.2.0 - 主要版本和次要版本+发布。

1.2.1 - 下一个版本

1.2.0_01 - 1.2.0版本（分支）中的错误修复

等

有什么想法吗？

Answer 1

我们使用major.minor.bugfix。主要版本只会发生巨大变化。当API发生变化时，会调用次要版本。所有其他版本都是bugfix版本。在故障排除中也有使用构建版本或修订版号的功能，但如果你有非常严格的CM，则可能不需要包含它。

在Apache Ivy或Maven等工具的帮助下，可以很好地协调所有这些项目的版本。一个项目的构建，具有自己的版本号，可能涉及其他项目（的产品）的特定版本的聚合，因此您的构建文件从下到上提供严格的版本映射。将此全部保存在[在此处插入喜爱的版本控制工具]中，您可以记录好的历史记录。

Answer 2

我使用{major}。{minor}。{buildday}。{sequential}。对于Windows，我们使用实用程序stampver.exe和UpdateVersion.exe来处理大多数自动处理的.NET项目。

Answer 3

没有标准的版本号系统。常见主题是主要，次要和内部版本号，偶尔也有一个点数（例如1.2.2.1版本1.2版本2版本1）。版本号的含义非常灵活。经常选择的是在次要版本或点发布之间具有向后兼容性。

只要源控件允许，就可以通过标记一组源控制文件来最好地完成发布。然后重新创建一个版本就像同步到标签和构建一样简单，这非常有用：）

Answer 4

在自动构建系统中，我目前正在使用带有Major.Minor.Build.X的I版本，每次我们进行系统测试时都是Build，而X是来自repo的最后一个Subversion修订版号，代码正在构建从。对于Subversion来说似乎工作得非常好，因为如果需要，我们可以很容易地回到特定构建的代码库。

Answer 5

我在linux内核版本编号系统上使用了一个变体：

major.minor.bugfix

即使是次要数字也表示可能至少在测试时发布的有些稳定的版本，奇数次要数字表示不应该在开发人员之外分发的不稳定/未经测试的版本。

Answer 6

在可能的情况下，我更喜欢使用相同的构建编号对项目进行版本控制，除非它们是共享的。它允许移动部件之间更加一致，并且更容易识别哪些组件构成产品发布。

正如workmad3所说，构建数字确实没有通用规则。我的建议是使用对你的团队/公司有意义的东西。

我工作过的一些地方已经将构建编号与项目里程碑和迭代进行了对齐，
例如：Major = Release或Milestone，Minor = Iteration，Build = Build number（从项目开始或从迭代开始），Revision =如果构建必须重建（或分支）。

Answer 7

最常见的约定之一是major.minor.bugfix，附加后缀表示内部版本号或预发布名称（例如alpha，beta等）。

我的团队编号根据项目里程碑进行构建 - 在开发迭代结束时（每隔几周），构建将交给我们的QA小组。临时CI构建没有编号;因为我们使用Maven，所以这些构建编号为SNAPSHOT后缀。

无论您决定什么，请务必记录下来并确保每个人都理解它。我还建议您记录并始终如一地应用发布分支策略，否则很快就会让每个人感到困惑。虽然只有4个项目，但跟踪发生的事情应该很容易。

Answer 8

您没有提及任何项目是否访问数据库，但如果有的话，这可能是另一个需要考虑的因素。我们使用一个major.minor.bugfix.buildnumber方案，类似于在这个问题的答案中描述的其他方案，具有大致相同的逻辑，但增加了要求任何数据库模式更改至少需要一个小的增量。这还为您的数据库模式提供了命名方案。例如，版本1.2.3和1.2.4都可以针对“1.2”数据库架构运行，但版本1.3.0需要“1.3”数据库架构。

Answer 9

目前我们还没有真正的版本。我们使用svn内部版本号和发布日期。 （标签名称类似于release_081010_microsoft，例如。）

旧版产品使用major.minor.sub版本编号

Major从未改变过 每6个月发布/发布一次微小变化。 Sub是不影响功能集的所有内容 - 主要是错误修正。