在C++项目中维护版本的好方法是什么？

Question

我们有一个C++项目,每个月都有数百个SVN版本.有时我们需要在版本号中增加一个小数字,将其从1.6更改为1.7.我们大约每个月做一次.这样做的正确方法是什么？我们希望保存/维护有关每个新版本所做更改的信息,并且我们希望获得某种发行说明.请给我们一些建议或链接.谢谢!

PS.对不起,如果问题太模糊了.

PPS.我看到我需要澄清一下这个问题.我对如何命名版本不感兴趣.我很感兴趣我在技术上应该如何在C++代码中维护版本号.

Answer 1

我将这个系统用于我写的所有软件:

1.2.3.4

1. 主要版本号.仅在增加众多产品功能的"主要"版本上增加.
2. 次要版本号.定期(季度,月度)版本的增量.这个数字不限于9; 随心所欲,随心所欲.不要为小修正或更新增加此值.更改主版本号时,此数字设置为零.
3. 更新号码.每当您发布一系列更新时,请递增此数字.我的书中的更新被认为是一个包含一系列错误修复,性能改进或安全增强功能的发行版.必须有多个更改才能增加.这也可以大于9.当更改次要版本号时,将重置为零.
4. 次要更新号码.通过轻微的个人变化来增加这一点.例如,如果您修复了特定的错误并将补丁推送到上一版本中,则会增加.更新号码更改时,此数字应重置为零.

最后,我使用以下后缀来表示预发布版本:

• b:Beta
• a:阿尔法
• rc:发布候选人

后缀后面可以跟一个数字,表示该包的预发布版本是哪个版本.例如:

1.2.3.4b2

将被视为第二个测试版.

此外,在编写版本时,可以消除尾随零.即:1.0.0.0可以写成1.0.

希望这有点有用.我发现它有助于保持组织有序并在我的档案中保持一些相似的顺序.

Answer 2

对于“发行说明”跟踪，我建议使用一些外部工具来跟踪任务。您可以分配功能，并在许多情况下将问题编号与特定的颠覆提交相关联。我过去曾使用 ClearQuest 和 Jira 来完成此任务，但您可以尝试一些开源/免费工具。

如果您决定遵循此路径，请确保每次提交都标有问题编号，并且所有问题都标有特定的软件版本号（“解决”）。为每个发现的错误打开一个问题。对于每个新版本，创建一个分支，合并标记有该版本中要解决的问题的提交，然后进行测试——有时您可能会与不适合此版本而是针对后续版本的更改发生冲突。合并、构建和测试分支后，从中创建发布标签。

生成发布文档非常简单：所有信息都存在于与当前版本号关联的问题跟踪器中。

我过去也看到过相反的工作方式：打开一个分支进行开发，在分支中执行单独的更改并将它们合并回主干，每个合并都包含整个更改的描述性文本——新功能或错误正在修复。需要时直接从主干创建发布标签。获取两个版本的更改只是读取从一个版本到下一版本的主干更改日志。

两种解决方案都存在相同类型的问题：合并在理论上是微不足道的，但在实践中却并非如此。在第一种情况下，当将代码从主干拉到发布分支时，当不拉动中间提交时，您将不得不处理合并问题。在分支中开发并合并回主干时，在每次合并到主干之前，您必须将第一个主干更改合并到分支中。构建、测试然后合并回主干。

大多数颠覆书籍都会推荐第二条路径，但在某些情况下，第一个路径（我当前使用的路径是有意义的）。在我们的例子中，我们有一整套运行超过 20 个小时的自动化测试，将所有代码直接写入主干意味着您只需要在那里运行自动化测试。如果我们为每个更改进行分支，要么我们会保留分支未经测试，直到我们合并回来——坏主意——否则我们将不得不投入更多的硬件进行测试并大大减慢开发速度。