Java 如何对项目进行版本设置并管理发布？

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

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

• 豆子
• 利用率
• 框架
• 网

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

最后，我们有一个客户项目，它由核心项目的特定版本和一个或多个模块组成

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

在我看来简单的事情变得非常复杂，因为我们试图向QA交付版本，然后通过维护版本（release=tag和可能的分支）来管理我们正在进行的开发

我比较喜欢以下几点：

1.2.0-主要和次要版本+发行版

1.2.1-下一版本

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

等等

---

有什么想法吗？

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

---

只要源代码管理允许，发布可能最好通过标记一组源代码管理的文件来完成。然后，重新创建一个发行版就像同步到标签和构建一样简单，这是非常有用的：）

在自动构建系统中，我当前使用的是带有Major.Minor.build.X的i版本，其中build是我们每次点击系统测试时的版本，X是构建代码的repo中的最后一个Subversion版本号。对于Subversion来说似乎工作得很好，因为如果需要，我们可以很容易地回到特定构建的代码库。

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

正如workmad3所说，构建编号实际上没有通用规则。我的建议是使用对您的团队/公司有意义的东西

我工作过的一些地方将构建编号与项目里程碑和迭代保持一致，

---

e、 g:Major=发布或里程碑，Minor=迭代，Build=构建编号（从项目开始或迭代开始），Revision=如果构建必须重建（或分支）。

我使用{Major}.{Minor}.{buildday}.{sequential}。对于Windows，我们使用实用程序和.NET项目，它们大部分是自动处理的

我们使用major.minor.bugfix。一个主要的版本只会发生巨大的变化。当API发生变化时，需要一个小版本。所有其他版本都是错误修复版本。有一个版本号或修订号在那里进行故障排除肯定是有用的，尽管如果你有非常严格的CM，你可能不需要包括它

---

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

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

目前我们没有真正的版本控制。我们使用svn版本号和发布日期。 （标签名称类似于发布版\u 081010\u microsoft，例如）

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

少校从未改变 每6个月对每个版本/功能版本进行一次小的更改。

---

Sub是所有不影响功能集的东西，主要是错误修复。

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

少校，少校，修正错误

---

其中，偶数次要数字表示可能至少为测试而发布的某种稳定版本，而奇数次要数字表示不稳定/未测试的版本，不应在开发人员之外发布。

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

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

---

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

我工作过的一个地方做了一些大-小错误修复，但它非常认真地只对大项目增加大项目。它们已经存在了15年，我正在开发最新最伟大的版本：1.52.0:）太棒了，我们也使用maven。听起来我们的计划和你说的很相似。我完全同意让其他人理解这个过程是关键。我们使用的是autopatch。它将自动保持数据库的最新状态