我有一个版本控制系统(例如Subversion),现在我想建立一个构建过程。现在我必须创建一个版本号并将其插入到系统中。但版本号来自何处?假设我想使用这个常见的< major>。< minor>。< bugfix / revision>方案。我应该将数字传递给构建脚本吗?或者我应该传递像increaseMajor,increaseMinor,increaseRevision这样的参数?或者,您是否建议使用构建脚本检测到的编号创建分支?
我可以想象主要和次要版本号必须手动放在某处。修订号可以自动增加。但我仍然不知道我将把主要和次要数字放在哪里。
在我的情况下,我有一些我想要压缩的php文件,但之前我必须在php文件中插入一些版本号。
我编辑了这篇文章,试图让我的要求更加清晰:
我不使用Subversion,这只是一个例子。我不想讨论版本号方案。
想象一下,我想创建版本3.5.0或3.5.1。我会将此版本号传递给构建脚本吗?脚本是否会使用此编号在存储库中创建分支,还是希望有人已创建此分支?手动?或者构建脚本是否会查找分支的名称(例如“3.5.1”)并将其用于其他内容?版本号是来自我的大脑还是自动创建(我猜它来自我的小脑和修订版号的主要/次要编号)?或者您是否将数字放入可能插入存储库的文件中?
我想如果使用版本管理工具,我会在那里插入版本号。但是我还没用过。
答案 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)