Hibernate 已迁移到 Git（托管在 GitHub 上）进行源代码控制。这已有很好的文档记录。我想描述 Hibernate 在分支、版本控制和发布方面所采取的方法，因为这已经在迁移到 Git 之前多次出现。
版本控制
对于版本控制，Hibernate 遵循 OSGi 指南，这些指南有很好的描述 在这里。以下是我们对 OSGi 版本中 组件
的看法
- 主版本 - 对 Hibernate 来说，这表示重大、破坏性的变更。回想一下 Hibernate2 到 Hibernate3 的迁移，这就是我所谈论的破坏性。从 3.x 到 4.x 的迁移在这方面将不那么破坏性，但仍有一个重大的变化。
- 次版本 - 我们有时将其称为系列，因此您可能会听到 Hibernate 开发者谈论 3.5 系列或 3.6 系列。在一个系列中，Hibernate 力求 API 稳定性。这个组件的变化（3.5 到 3.6）表示一些 API 变化，尽管它通常是一个添加，因此比上面讨论的破坏性小。
- 修订版本 - 对 Hibernate 来说，这些表示错误修复版本。
- 修饰符 - Hibernate 实际上只使用这个组件来表示预发布版本（alpha、beta 等）。一旦我们达到最终版本（x.y.0.Final），我们就开始增加修订版本，但继续使用 Final 修饰符（x.y.1.Final）进行发布排序（因此是范围）。
维护分支
Hibernate 为每个（主.次）版本系列维护分支。在迁移到 GitHub 的过程中，我们趁机删除了非常旧的分支。所以目前有 修复分支
用于 3.2、3.3、3.5 和 3.6（当前 master
分支在进行 4.0 的工作）。我们创建分支是为了能够将这些修复移植回去。例如...当前活跃的维护分支是 3.6；master
是 4.0 的持续工作。4.0 有很多颠覆性的变化，如上所述（尽管由于 API 差异，系列变化也适用同样的讨论）。有两个分支使我们能够同时工作在两个代码库上。我们可以修复一个错误，并将该更改应用到 4.0 和 3.6 代码库；而 4.0 可以像需要那样独立发展。在 master
上，Hibernate 已经将其构建工具迁移到 Gradle，同时我决定迁移到一个更标准的模块目录命名方案；不幸的是，这给回滚修复带来了一些有趣的挑战，我将在另一篇博客中讨论。
维护版本
Hibernate 从 活跃维护分支
进行维护版本发布。目前，这意味着我们将从 3.6 分支进行维护版本发布。我们将继续这样做，直到 4.0 成为最终版本，届时我们将停止 3.6 的维护，将 4.0 作为活跃维护分支，并将 master 移动到 4.1 开发。这是我们遵循的一般概述。例如，回顾 3.6 开发，你可以看到这一点。我们一直保持 3.5 的维护版本发布，直到 3.6 成为最终版本。
时间框
Hibernate 团队对版本发布遵循一个时间框计划。我个人不相信这里的僵化，尤其是对于维护版本。我们已成为遵循时间框进行 Alpha、Beta 和 CR 发布的优秀团队，我认为这是最大的好处。我们选择了两周的 Beta 和 CR 发布时间框，在我看来效果非常好。我们为 Alpha 做过两周和四周的时间框；我们将继续调整这一点（就像我认为 4.0 开发将使用四周时间框一样，因为变化如此之多）。
