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