版本号怎么办？

我的公司正在生产产品。它将由SVN版本化。它是一个webapp，因此基本上不会有没有某些功能的版本，因此总是可以标记为beta。但是由于它将成为企业产品，所以我真的不希望出现“不稳定的监视”。那么您将如何进行版本控制？1.0稳定吗？构建日期应该在版本号中吗？告诉我你们在想什么！

[ major ]。[ minor ]。[ release ]。[ build ]

major：真正的市场决策。您准备好调用1.0版本了吗？公司是否将其视为客户可能需要支付更多费用的主要版本，还是它是当前免费的主要版本的更新？更少的研发决策，更多的是产品决策。

minor：每当major递增时，从0开始。每个公开的版本+1。

释放：每次达到开发里程碑并发布产品时，甚至在内部（例如进行质量检查），都应增加发行量。这对于组织中团队之间的沟通尤为重要。不用说，永远不要两次发布相同的“发布”（即使在内部）。在次要++或主要++上重置为0。

build：可以是SVN修订版，我发现效果最好。

示例
我当前的Chrome：83.0.4103.61

y

g的增量不稳定。（或RC）在z中的增加是稳定的，并且平均修复了错误。
y的增量稳定且意味着新特征。
x的增量是稳定的，主要发行版本，没有100％向后兼容。

我曾经为我的一个大型项目编写了详尽的“版本样式指南”。该项目未能实现，但是样式指南仍然可以在线获得。这是我的个人观点，也许对您有所帮助（或鼓舞人心）。

请注意，这是一长篇文章，涉及组件版本控制与产品版本控制之类的内容。它还对OSS社区中流行的某些版本控制方案表达了强烈的意见，但是我有它们，因此我表达了它们。;-)

例如，我不同意使用Subversion修订版号。您可能需要在继续在TRUNK中进行开发的同时维护发行版，所以您将建立一个维护分支-这样您的修订号版本控制就不那么容易了。

编辑：作为总结，它区分版本控制源文件，组件和整个产品。它对组件和产品使用单独的xy版本检查系统，两者之间具有很好的相互依赖性，因此可以轻松地跟踪哪个组件版本属于哪个产品版本。它还讨论了如何在不中断系统的情况下处理alpha / beta / release / patch周期。实际上，这是整个开发周期的一种操作方式，因此您可能需要选择。;-)

编辑2：当足够多的人发现我的文章对使它成为“很好的答案”有用时，我又开始着手研究该文章。现在可以使用PDF和LaTeX版本，我会在发现时间后立即进行全面重写，包括更好的语言和说明性图形。谢谢您的投票！

从Wikipedia获得一些启发：“软件版本控制”

另一个“新”和“相对流行”的选项是语义版本控制

摘要：

给定版本号MAJOR.MINOR.PATCH，增加：

1. 当您进行不兼容的API更改时的主要版本，
2. 以向后兼容的方式添加功能时的MINOR版本，并且
3. 进行向后兼容的错误修复时的PATCH版本。

可以使用预发布和构建元数据的其他标签作为MAJOR.MINOR.PATCH格式的扩展名。

A B C D

增量：当
- d：bug修复
- Ç：维护，如绩效改进
- b：新功能
- 一：结构变化

强制项是最左边的一项，例如，如果有一个新功能和一个错误修复，那么您只需要增加b即可。

基于我在复杂的企业平台级别的依赖关系管理和发行版本控制方面的经验，我来推荐一种我喜欢称之为“ 半语义版本控制”的方法。

基本上，它是基于语义版本2.0构建的，但并不那么严格。

半语义版本细分：

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

主要版本细分格式：

市场，主要，次要补丁

每个段都应允许使用字母数字，但对于逻辑增量更改，建议使用纯数字。

与SemVer一样，我建议使用Major，Minor和Patch组件来表示反向兼容性层，但我也建议在Marketing组件之前添加。这使产品所有者，功能史诗/组和业务关注点能够独立于技术兼容性关注点而碰撞主要组件。

与其他答案不同，我不建议在主要段后面附加内部版本号。而是在“ +”之后添加发布后细分（例如：1.1.0.0 + build.42）。SemVer将此构建元数据称为“构建元数据”，但我认为“发布后细分”更为清晰。该段非常适合于声明后缀数据与主数据库中的兼容性信息无关发行版中。然后，可以为您的持续集成版本提供先前的版本号，并附加一个递增的内部版本号，该增量的内部版本号在每个主要版本后都会重置（例如：1.1.0.0-> 1.1.0.0 + build.1-> 1.1.0.0 + build.2-> 1.1.0.1）。有些人喜欢将svn修订版号或git commit sha放在此处，以便轻松绑定到代码存储库。另一个选择是将发布后部分用于修复程序和补丁，因此可能值得考虑为此添加新的主要发布组件。当补丁组件增加时，它总是会掉落，因为版本实际上是左对齐和排序的。

除了发行和发行后细分，人们经常希望使用“ 发行前”细分来表示几乎稳定的预发行，例如alpha，beta和候选发行。SemVer方法可以很好地解决此问题，但是我建议将数字成分与字母数字分类器（例如：1.2.0.0 + alpha.2或1.2.0.0 + RC.2）分开。通常，您会在添加发布后段的同时更改发布段，然后在下次将它们更改为主发布段时将其释放（例如：1.0.1.2-> 1.2.0.0-RC.1- > 1.2.0.0）。添加了预发行段以指示即将发布发行版本，通常只是一组固定的功能，用于进行更深入的测试和共享，而不会随着提交的增加而每分钟更改一次。

以涵盖几乎所有用例的方式对所有这些语义进行定义的好处在于，您可以以标准方式对其进行解析，排序，比较和递增。当将CI系统用于具有许多小型独立版本化组件（例如微服务）的复杂应用程序时，这一点尤其重要，每个组件都有自己的托管依赖项。

如果您有兴趣，我用ruby编写了一个半语义解析器。我不仅需要使用此模式，还需要能够管理使用该模式的其他应用程序。

“版本号”与内部版本控制系统有关。版本号是另一回事（应该保持不同）。

坚持使用简单的MAJOR.MINOR发布系统（如v1.27），其中MAJOR是兼容性级别（版本2.x与版本1.x不兼容或至少与版本1x至少有很大不同），而MINOR是您的错误修正版本或较小的增强功能。只要遵循XY格式，您还可以使用其他系统，例如YEAR.MONTH（2009.12）或YEAR.RELEASE（2009.3）。但是实际上，除非您有充分的理由不这样做，否则最好还是坚持使用MAJOR.MINOR。

绝对不要使用任何不适合XY格式的内容，因为它会使发行版，公告网站等难以与您一起工作，仅此一项就可能严重影响您的项目的受欢迎程度。

在（最好是分布式的）版本控制系统中使用分支和标记将特定的内部版本号标记为分别与MAJORS和MINORS相关。

是的，1.0应该是稳定的。除非标有alpha，beta或RC，否则所有版本均应稳定。使用Alpha表示已知的残缺和不完整。Beta已知破损。RC表示“尝试；您可能会发现我们错过的事情”。任何没有这些的东西（当然，理想情况下）都应该经过测试，已知良好，具有最新的手册等。

如今，仅使用Subversion修订版号非常流行。

如果在SVN中，那么为什么不使用SVN版本号呢？

如果查看此网页的右下角，您会看到Stack Overflow版本号，它是SVN修订版号。

版本取决于您；我将1.0放到我有信心的第一个版本中。由于某些软件供应商对1.0的口碑不好，因此您可能希望将其与其他版本一起快速使用。

您确实希望通过某种方式将版本号绑定到所使用的确切版本，但是您可能希望它对最终用户而言既简单又好用。考虑使用标准版本号，并使用随附的版本号标记SVN存储库。

虽然仅使用Subversion修订版号就很方便，但它确实从版本号中删除了信息。用户可能认为这是一件坏事。

我假设您的Web应用程序将具有某种部署过程，因此并不是实际上发布了Subversion中的每个修订。由于不可能从外部（从用户的角度）确定发布的时间以及代码在它们之间进行多少次修订，因此它使数字几乎是随机的。它们会增加，我想可能有一些推测通过比较两个修订某种距离，但幅度不大。

古典版本号倾向于“戏剧化”发布，以便用户可以建立某种期望。相比“昨天我们运行SO版本2587，今天是3233版本，一定要好得多！”，认为“我有1.0版，现在1.1版已经添加了这个，那听起来很有趣”。

当然，这种戏剧性也可能被夸大，因为公司选择的版本号听起来比产品实际差异所激发的有趣，我猜想版本号会对此有所反作用。

版本方案：[major]。[minor]。[devrel] [mark]
[major]：如果您的开发发生了重大变化，则增加。
[小]：如果您的开发有微小变化，则增加。
[devrel]：如果有错误修复，则增加。如果是major ++或minor ++，则重置为零。
[mark]：a，b或rc：a是alpha版本，b是beta版本，rc是候选版本。请注意，像1.3.57a或1.3.57b或1.3.57rc这样的版本早于1.3.57。从0.0.0开始。

我们花了太多时间来决定何时增加主要版本。有些商店很少这样做，因此您会发布1.25.3之类的版本，而另一些商店则永远发布，给您15.0的版本。

我对此感到厌烦，并说服所有人，主要发行版号只是年份，次要发行版只是该年内的连续发行版。用户似乎很喜欢它，因此下一个版本号就很容易了。

Year.Release.build

• 年=当年
• 版本=具有新功能的公共版本的序列号-每年重置为1
• 内部版本=修正错误和内部发行版本

编辑

**现在这是一个不断增强的内部应用程序**

这可能不适用于商业应用程序，因为出于营销和财务目的，一年中的不同时间发布重要版本非常重要。

之所以存在这个问题，是因为我们没有一种达成共识的方式来进行配置管理。

我喜欢做版本号的方法只是从1开始递增整数。我不需要一个我必须解释或记录的多部分版本号。我也不想使用SVN版本号，因为这也需要一些解释。

您可能需要在SVN之上使用一些发布脚本来实现此目的

我在该地区的经验很少。但是，这是我要做的：

1. 选择用于修订版本的编号方案并坚持使用。始终如一。
2. 每个版本更改都代表一个重大更改。更改有多小是重要的，版本号中反映的更改级别由您决定。

当然，您可以只使用svn修订号---就像许多其他建议一样！

我希望这有帮助。

我们使用简单的major.minor.julian_date语法。

哪里;

• major-第一个发行版是1，然后当我们引入主要的新功能或重要更改时，它们之间不具有向后兼容性，因此会增加此数量。
• 次要-主要里程碑发布。对于生产推动的每个构建，此数字都会增加。
• julian_date- 构建的儒略日被推入质量检查。

在1/15推送到QA
的第一个发行版的示例是-> 1.0.015 在3/4推送到Production的第一个发行版的示例是-> 1.1.063

它不是完美的，但是在我们几乎每天都将构建推送到质量检查时非常方便。

一些很好的信息在这里：

何时更改文件/程序集版本

首先，文件版本和程序集版本不需要相互一致。我建议文件版本随每次构建而更改。但是，请勿仅更改每个内部版本的程序集版本，以使您可以分辨出同一文件的两个版本之间的区别；为此使用文件版本。在决定何时更改部件版本时，需要考虑一些要考虑的构建类型：运输和非运输。

非运输版本通常，我建议非运输部件版本在运输版本之间保持相同。这样可以避免由于版本不匹配而引起的名称广泛的程序集加载问题。有些人喜欢使用发布者策略来重定向每个版本的新程序集版本。对于非运输版本，我建议不要这样做：它不能避免所有的加载问题。例如，如果合作伙伴x复制了您的应用程序，则他们可能不知道要安装发布者策略。然后，即使它们在您的计算机上正常运行，您的应用程序也会被破坏。

但是，如果在某些情况下，同一台计算机上的不同应用程序需要绑定到程序集的不同版本，则我建议为这些程序生成不同的程序集版本，以便无需使用LoadFrom / etc即可使用每个应用程序的正确版本。

运送版本至于更改运送版本的版本是否是一个好主意，则取决于您希望绑定对最终用户起作用的方式。您是否希望这些构建并排或就位？两次构建之间有很多变化吗？他们会破坏一些客户吗？您是否在意它会破坏它们（还是要强迫用户使用您的重要更新）？如果是，则应考虑增加程序集版本。但是，再一次，请考虑这样做太多会浪费用户程序集的磁盘空间。

更改程序集版本时若要将硬编码版本更改为新版本，建议将变量设置为头文件中的版本，并用变量替换源中的硬编码。然后，在构建过程中运行预处理程序以放入正确的版本。我建议在发货后立即更改版本，而不是在此之前更改版本，以便有更多时间来捕获由于更改而导致的错误。

或使用您的“思想型”版本号逗号替换号。zB：

1.0.101 //修订版101，发布

或1.0.101-090303 //发布日期，我用这个