我们的情况如下，但我对这个问题在任何情况下都很好奇。
我们有一个由 4 个项目组成的框架：
我们还有一些模块需要一个版本，并且依赖于一个版本的 beans 和 util。
最后我们有一个客户项目，它由一个特定版本的核心项目和一个或多个模块组成。
是否有标准方法来对这些项目进行版本控制？
在我看来简单的事情变得非常复杂，因为我们尝试将发布交付给 QA，然后通过维护发布（发布 = 标签和可能的分支）来管理我们正在进行的开发。
我比较喜欢以下：
1.2.0 - 主要和次要版本 + 发布。
1.2.1 - 下一个版本
1.2.0_01 - 1.2.0 版本（分支）中的错误修复
等等
有什么想法吗？
【问题讨论】：
标签： java language-agnostic maven-2 versioning
最常见的约定之一是major.minor.bugfix，附加后缀表示内部版本号或预发布名称（例如alpha、beta等）。
我的团队编号是根据项目里程碑构建的 - 在开发迭代结束时（每隔几周），构建会移交给我们的 QA 小组。临时 CI 构建没有编号；因为我们使用 Maven，所以这些构建以 SNAPSHOT 后缀编号。
无论您做出什么决定，请务必记录下来并确保每个人都理解它。我还建议您记录并一致地应用发布分支策略，否则它很快就会让每个人都感到困惑。虽然只有 4 个项目，但应该很容易跟踪正在发生的事情。
【讨论】：
我使用 {major}.{minor}.{buildday}.{sequential}。对于 Windows，我们将实用程序 stampver.exe 和 UpdateVersion.exe 用于大部分自动处理的 .NET 项目。
【讨论】：
我在 linux 内核版本编号系统上使用了一个变体：
major.minor.bugfix
其中偶数次要数字表示一个稍微稳定的版本，至少可以分发用于测试，而奇数次要数字表示一个不稳定/未经测试的版本不应分发给开发人员。
【讨论】：
目前我们没有真正的版本控制。我们使用 svn 内部版本号和发布日期。 （标签名称例如 release_081010_microsoft）
旧产品使用major.minor.sub 版本编号
专业从未改变 每 6 个月对每个版本/功能发布进行细微更改。 Sub 是不影响功能集的所有内容 - 主要是错误修复。
【讨论】：
您没有提及是否有任何项目访问数据库，但如果有的话，这可能是另一个需要考虑的因素。我们使用了一个major.minor.bugfix.buildnumber 方案，类似于此问题的答案中描述的其他方案，具有大致相同的逻辑，但增加了任何数据库模式更改至少需要小幅增量的要求。这也为您的数据库模式提供了一个命名方案。例如，1.2.3 和 1.2.4 版本都可以针对“1.2”数据库架构运行，但 1.3.0 版本需要“1.3”数据库架构。
【讨论】：
我们使用major.minor.bugfix。一个主要版本只发生在巨大的变化上。当 API 发生更改时，将调用次要版本。所有其他版本都是错误修复版本。那里有一个内部版本号或修订号对于故障排除肯定是有用的，但如果你有非常严格的 CM，你可能不需要包含它。
在 Apache Ivy 或 Maven 等工具的帮助下，可以很好地协调所有这些项目的版本。一个项目的构建，具有自己的版本号，可能涉及到其他项目（产品）的特定版本的聚合，因此您的构建文件提供了自下而上的严格版本映射。将其全部保存在 [在此处插入最喜欢的版本控制工具] 中，您就有了一段美好的历史记录。
【讨论】：
如果可能，我更喜欢使用相同的构建编号对项目进行版本控制，除非它们是共享的。它允许移动部件之间的一致性更高，并且更容易识别哪些组件构成产品发布。
正如 workmad3 所说，内部版本号确实没有通用规则。我的建议是使用对您的团队/公司有意义的东西。
我工作过的一些地方将构建编号与项目里程碑和迭代保持一致，
例如：Major = Release 或 Milestone，Minor = Iteration，Build = Build number（从项目开始或从迭代开始），Revision = 如果必须重新构建（或分支）构建。
【讨论】：
在自动构建系统中，我目前正在使用带有 Major.Minor.Build.X 的 I 版本，其中 Build 是每次我们进行系统测试时，X 是正在构建代码的 repo 中的最后一个 Subversion 修订号从。似乎在 Subversion 上工作得很好，因为如果需要，我们可以轻松地回到特定构建的代码库。
【讨论】：
没有标准的版本号系统。常见的主题是有一个主要、次要和内部版本号，偶尔还有一个点号（例如，1.2.2.1，对于版本 1.2 点版本 2 版本 1）。版本号的含义非常灵活。一个常见的选择是在次要版本或点版本之间具有向后兼容性。
只要您的源代码管理允许，最好通过标记一组源代码控制文件来完成发布。重新创建一个版本就像同步到标签和构建一样简单，这非常有用:)
【讨论】：