版本号来自哪里?

时间:2009-01-20 12:58:20

标签: version-control version-numbering

我有一个版本控制系统(例如Subversion),现在我想建立一个构建过程。现在我必须创建一个版本号并将其插入到系统中。但版本号来自何处?假设我想使用这个常见的< major>。< minor>。< bugfix / revision>方案。我应该将数字传递给构建脚本吗?或者我应该传递像increaseMajor,increaseMinor,increaseRevision这样的参数?或者,您是否建议使用构建脚本检测到的编号创建分支?

我可以想象主要和次要版本号必须手动放在某处。修订号可以自动增加。但我仍然不知道我将把主要和次要数字放在哪里。

在我的情况下,我有一些我想要压缩的php文件,但之前我必须在php文件中插入一些版本号。


我编辑了这篇文章,试图让我的要求更加清晰:

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

想象一下,我想创建版本3.5.0或3.5.1。我会将此版本号传递给构建脚本吗?脚本是否会使用此编号在存储库中创建分支,还是希望有人已创建此分支?手动?或者构建脚本是否会查找分支的名称(例如“3.5.1”)并将其用于其他内容?版本号是来自我的大脑还是自动创建(我猜它来自我的小脑和修订版号的主要/次要编号)?或者您是否将数字放入可能插入存储库的文件中?

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

5 个答案:

答案 0 :(得分:5)

对于subversion,要么采用全局修订号,要么将其用作“构建”号,或者更好的是,根本不依赖它并管理带有标记和/或分支的版本。全球修订的主要问题恰恰在于它对回购而言是全球性的。即使回购的某些部分没有改变,它也会增加。

完全取消版本与回购订单的修订是恕我直言的更好。你有标签,使用它们。

答案 1 :(得分:2)

同意以前所有关于分支和标签的使用。另外,分支名称和标记名称可以与一些聪明的脚本编写合并到构建过程中。

我希望添加的唯一信息是你应该将你的SVN版本隐藏到每个版本中。有时很容易回到修订版的某一点,而不是知道标签或分支。 99%的标签/分支足够好,但修订版对于增量/内部/连续/测试版本非常有用。

答案 2 :(得分:2)

应手动创建所有分支。构建脚本应该在标签和/或分支上工作,从检出(或可能正在更新)开始。作为构建过程的一部分,最好在构建的确切快照上创建标记。

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

版本通常存储在每个发布周期手动更新一次的文件中。它被检查进入分支,然后单独留下。例如,主线在其文件中将具有version =“3”,发布分支上的第一个版本将具有版本=“3.5”,并且如果需要修补程序版本,则将其从发布分支分支并签入版本= “3.5.1”

答案 3 :(得分:1)

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

您可以通过多种方式强制执行版本号。通常在subversion中,您可以为构建创建一个分支(或标记,它们本质上是相同的东西),如果这是一个发布版本,您可以为此创建一个标记,例如svn://my-repo/releases/1.0.0 < / p>

您可以将参数传递到构建脚本中以获取代码并将其用作构建号,或者使用构建脚本使用的目录,并将svn切换到您要构建的分支,脚本可以使用svn info来确定它正在构建的版本。

答案 4 :(得分: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)