6

我有一个版本控制系统（例如 Subversion），现在我想建立一个构建过程。现在我必须创建一个版本号并将其插入系统。但是版本号是从哪里来的呢？假设我想使用这个常见的 <major>.<minor>.<bugfix/revision> 方案。我应该将一个数字传递给构建脚本吗？或者我应该传递像 increaseMajor、increaseMinor、increaseRevision 这样的参数吗？或者您会建议使用构建脚本将检测到的编号创建一个分支吗？

我可以想象主要和次要版本号必须手动输入某个地方。修订号可以自动增加。但是我仍然不知道将主要和次要号码放在哪里。

就我而言，我有一些我想压缩的 php 文件，但在我必须将一些版本号插入 php 文件之前。

我编辑了这篇文章，试图让我的要求更清楚：

我不使用 Subversion，这只是一个例子。而且我不想讨论版本号方案。

想象一下，我想创建 3.5.0 或 3.5.1 版本。我会将此版本号传递给构建脚本吗？脚本会在存储库中使用此编号创建分支，还是希望有人已经创建了此分支？手动？或者构建脚本会查找分支的名称（例如'3.5.1）并将其用于其他事情吗？版本号是来自我的大脑还是自动创建的（我猜它来自我的小大脑并创建了修订号）？或者您会将数字放入可能插入存储库的文件中？

我想如果会使用发布管理工具，我会在那里插入版本号。但我还没用过。

4

5 回答 5

5

对于颠覆，要么采用全局修订号并将其用作“构建”号，或者更好的是，根本不依赖它并使用标签和/或分支管理版本。全局修订的主要问题正是，它对 repo 是全局的。即使回购的某些部分没有改变，它也会增加。

恕我直言，将版本与 repo 的修订完全分离更好。你有标签，使用它们。

于 2009-01-20T13:06:39.453 回答
2

同意所有以前关于使用分支和标签的意见。另外，分支名称和标签名称可以通过一些巧妙的脚本合并到构建过程中。

我想补充的唯一一点是您应该将您的 SVN 修订版偷偷带入每个构建中。有时很容易通过修订返回到某个点，而不是知道标签或分支。99% 的标签/分支已经足够好，但修订版非常适合增量/内部/连续/测试构建。

于 2009-01-21T12:19:39.047 回答
2

所有分支都应手动创建。构建脚本应该处理一个标签和/或分支，从检查它开始（或者可能正在更新它）。作为构建过程的一部分，在构建的确切快照上创建标签是个好主意。

您通常会有内部版本号和版本。内部版本号可以自动增加并作为构建的一部分签入版本控制（基于标签的构建除外，其中内部版本号必须保留在存储库之外 - 避免基于标签的构建的另一个原因）。

版本通常存储在一个文件中，您在每个发布周期手动更新一次。它被检入正确的分支，然后单独离开。例如，主线文件中的 version = "3"，release 分支上的第一个修订版本 = "3.5"，如果需要补丁版本，则将其从 release 分支分支并签入 version = “3.5.1”

于 2009-01-21T13:28:23.993 回答
1

svn 或任何其他版本控制系统中的修订版与您的产品版本号（甚至您的内部版本号）不同。

您可以通过多种方式强制执行版本号。通常在颠覆中，您可以为构建创建一个分支（或标签，它们本质上是相同的），如果这是一个发布版本，您为此创建一个标签，例如 svn://my-repo/releases/1.0.0

您可以将参数传递给构建脚本以获取代码并将其用作构建号，或者拥有构建脚本使用的目录，然后 svn 将其切换到您想要构建的分支，脚本可以使用 svn信息来确定它正在构建什么版本。

于 2009-01-20T13:08:19.870 回答
0 
x.y.i.j

其中x- 主要版本，y- 次要版本，i- 内部版本号，j- 修订号

Major version主要更改的增量（新架构、新 UI 等）

Minor version微小变化的增量（性能改进，主要错误修复等），

Build number每次公开发布时都会增加。

Revision number每次提交对项目源代码树的更改时递增。

我更喜欢将 0 作为修订号指向 AssemblyInfo.cs，并将实数指向发布包的名称（foo-1.1.7.110-source.zip）

于 2009-01-21T12:08:33.143 回答