如何做版本号？
我公司正在build设一个产品。 这将由SVN版本化。 这是一个web应用程序，所以基本上不会有一个版本，它没有在其中的某些function，因此可以永远被标记为testing版。 但是，既然这将是一个公司产品，我真的不希望那里的“不安定的监视”。 那么你将如何去版本？ 是1.0稳定？ 生成date是否在版本号？ 告诉我你们在想什么！
[ major ]。[ minor ]。[ release ]。[ build ]
重大 ：真是一个营销决定。 你准备好打电话给1.0版吗？ 公司是否认为这是一个客户可能需要支付更多费用的主要版本，还是免费更新当前的主要版本？ 更less的研发决定和更多的产品决策。
次要 ：每增加一次，从0开始。 每个版本上市+1。
发布 ：每当您达到开发里程碑并发布产品时，即使是在内部（例如QA），也要增加这个。 这对组织中团队之间的沟通尤为重要。 不用说，永远不要释放两次（甚至内部）相同的“释放”。 在轻微++或主要++时重置为0。
构build ：可以是一个SVN修订，我觉得效果最好。
xyzg
g中的增量是不稳定的。 （或RC）在z中的增量是稳定的，并意味着错误修复。
y的增量是稳定的，意味着新的function。
x中的增量是稳定的，主要发行没有100％的向后兼容性。
我曾经为一个大型的项目编写了一个精心制作的“版本风格指南”。 该项目未能实现，但风格指南仍然可以在线获得 。 这是我个人的看法，也许对你有帮助（或鼓舞人心）。
注意，这是一个长文本，并进入组件版本控制与产品版本控制等等。 对于OSS社区中stream行的一些版本pipe理scheme，也expression了强烈的意见，但是我也有，所以我expression一下。 😉
例如，我不同意使用Subversion版本号。 您可能需要在TRUNK中继续开发的同时维护一个发行版本，这样您就可以build立一个维护分支 – 而且您的修订版本版本将不复存在。
编辑：作为一个总结，它区分版本源文件，组件和整体产品。 它使用一个单独的组件和产品的xy版本的系统，两者之间有很好的相互依赖关系，使得跟踪哪个组件版本属于哪个产品版本是不重要的。 它还谈到如何在不破坏系统的情况下处理alpha / beta / release / patch周期。 事实上，这是整个开发周期的一种手法，所以你可能要挑选。 😉
编辑2：当有足够的人发现我的文章有用，使这是一个“不错的答案”，我开始再次工作的文章。 PDF和LaTeX版本现在已经可用，包括更好的语言和解释性graphics的完整重写将尽快find时间。 感谢您的投票！
从维基百科获得灵感： “软件版本控制”
另一个“新”和“相对stream行”选项是语义版本
概要：
给定版本号MAJOR.MINOR.PATCH，增加：
- MAJOR版本，当您进行不兼容的API更改时，
- MINOR版本，当您以向后兼容的方式添加function时
- 当您进行向后兼容的错误修复时，修补程序版本。
预发布和构build元数据的其他标签可作为MAJOR.MINOR.PATCH格式的扩展使用。
基于我在复杂的企业平台级别依赖pipe理和版本发布方面的经验，我推荐了一种我喜欢称为“ 半语义版本控制”的方法 。
基本上它基于语义版本2.0而不是非常严格。
半语义版本段：
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
主要发布段格式：
MARKETTING.MAJOR.MINOR.PATCH
每个段应允许使用字母数字，但build议对逻辑增量更改使用纯数字。
像SemVer一样，我推荐使用Major，Minor和Patch组件来表示反向兼容层，但我也build议预先添加一个Marketing组件 。 这使得产品所有者，function史诗/组和业务问题能够独立于技术兼容性问题而冲击主要组件。
与其他答案不同，我不build议在主段上添加一个Build号码。 相反，在“+”（例如：1.1.0.0 + build.42）之后添加一个发布后版块。 SemVer称这个构build元数据，但我认为后释放段更清晰。 该段非常适合将后缀数据声明为与主要版本段中的兼容性信息无关。 然后，您的持续集成构build可以赋予之前的版本号，并附加一个在每个主要版本之后重置的增量构build号（例如：1.1.0.0 – > 1.1.0.0 + build.1 – > 1.1.0.0 + build.2 – > 1.1.0.1）。 有些人交替地喜欢把svn修订号码放在这里，或者是git commit sha，这样可以很容易的绑定到代码库。 另一个select是使用发布后版本的修补程序和修补程序，因此可能需要考虑为其添加新的主要发行版组件。 当补丁组件增加时，它总是可以被丢弃，因为版本是有效的左alignment和sorting的。
除了发布和发布后的细分市场，人们通常希望使用预发布细分来表示几乎稳定的预发布，如alpha，beta和发布候选。 对此的SemVer方法效果很好，但是我build议从字母数字分类器（例如：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）。 预发行版段被添加来指示发行版本即将发布，通常只是一组固定的function，以便进行更深入的testing和共享，这些function基于更多的提交不会一分一秒地改变。
以涵盖几乎所有用例的方式在语义上定义所有这一点的美妙之处在于，您可以以标准方式parsing，sorting，比较和增加它们。 将CI系统用于具有许多小型独立版本化组件（如微型服务）的复杂应用程序时，这一点尤为重要，每个组件都有自己的托pipe依赖关系。
如果你有兴趣，我写了一个ruby的半语义parsing器 。 我需要不只是使用这种模式，但能够pipe理使用它的其他应用程序。
A B C D
增量：何时
– d ：错误修复
– c ：维护，例如性能改进
– b ：新function
a ：架构改变
强制性是最左边的一个，例如，如果有一个新的function和一个bug修复，那么你只需要增加b 。
现在使用Subversion版本号是非常受欢迎的。
“版本号”是您的内部版本控制系统的问题。 发行号码是一个不同的问题（应该是KEPT不同）。
坚持一个简单的MAJOR.MINOR发布系统（如v1.27），其中MAJOR是兼容性级别（版本2.x与版本1.x不兼容或至less大不相同）和MINOR是您的bug修复版本或次要的增强。 只要您遵循XY格式，您还可以使用其他系统，如YEAR.MONTH（2009.12）或YEAR.RELEASE（2009.3）。 但是，除非你有充分的理由不这样做，否则你最好坚持MAJOR.MINOR。
绝对不要使用任何不适合XY格式的东西，因为它会使发行版，公告网站等与您合作，这样会严重影响您的项目受欢迎程度。
在您的（最好是分布式）版本控制系统中使用分支和标签来分别标记与MAJORS和MINORS相关的特定内部版本号。
是的，1.0应该是稳定的。 所有版本应该是稳定的，除非它们被标记为alpha，beta或RC。 使用阿尔法已知破碎和不完整。 贝塔斯已知的破碎。 “尝试它，你可能会发现我们错过的东西”的RC。 任何没有这些的应该（当然，理想情况下）应该被testing，已知的好，有一个最新的手册等。
如果它在SVN中，那么为什么不使用SVN修订号？
如果你看看这个网页的右下angular，你会看到堆栈溢出版本号，这是SVN版本号。
版本是由你决定的; 我在第一个版本中放了1.0，我有信心，你可能想跟其他版本一起，因为一些软件厂商已经给1.0一个坏名声。
你需要一些将版本号绑定到使用的确切版本的方法，但是你可能希望它对你的最终用户来说很好，很简单。 考虑使用标准版本号，并用包含的版本号标记SVN存储库。
而使用Subversion版本号很简单，它会从版本号中删除信息。 用户可能认为这是一件坏事。
我假设你的web应用程序将有某种部署过程，所以Subversion中的每个修订版本都不是真正发布的。 由于从“外部”（从用户的angular度）来确定什么时候发布，以及代码将在它们之间经历多less次修改是不可能的，所以它使得这些数字几乎是随机的。 他们会越来越多，我想可以从比较两个修订版中推测出一些距离，但不是太多。
古典版本的数字倾向于“戏剧化”发布，以便用户可以build立某种期望。 想想“我有1.0版本，现在版本1.1join了这个，这听起来很有趣”，而不是认为“昨天我们运行SO修订版2587，今天是3233，它肯定要好很多！”。
当然，这个戏剧化也可以被夸大，公司select的版本号比起产品的实际差异来说更有意思，我想跟修订号这个一点点。
我们花了太多时间来决定何时增加主要版本。 有些商店很less这样做，所以你会有像1.25.3这样的版本，而其他的版本会永远释放，给你15.0
我厌倦了这一点，并说服大家的主要版本号只是一年，而未成年人只是在一年内的顺序释放。 用户似乎喜欢它，并且用下一个版本号来取代它是一件简单的事情。
Year.Release.build
- 年份=当年
- release =具有新function的公开发布序列号 – 每年重置为1次
- build = bug修复和内部版本增加
编辑
**现在这是一个不断增强的内部应用程序**
这对于商业应用程序来说可能不适用，因为在市场和财务目的的一年中的不同时间发布重要版本非常重要。
版本scheme：[major]。[minor]。[devrel] [mark]
[专业]：如果你的发展有很大的改变，就会增加。
[轻微]：如果你的开发有小的变化就增加。
[devrel]：如果你有错误修正，则增加。 如果主要++或次要++重置为零。
[mark]：a，b或rc：a是alpha版本，b是beta版本，rc是版本候选版本。 请注意，1.3.57a或1.3.57b或1.3.57rc等版本在版本1.3.57之前。 从0.0.0开始。
我在这方面的经验很less。 但是，这是我会做的：
- select编号修订的scheme并坚持下去。 始终如一。
- 每个版本的变化应该是一个重大的变化 。 一个变化是多么的重要，并且在版本号中反映的变化水平取决于你。
当然，你可以像使用其他许多人所build议的那样使用svn修订版本号。
我希望这有帮助。
这个问题存在的原因是因为我们没有一个统一的方式来进行configurationpipe理。
我喜欢的版本号的方式是从1递增整数。我不想要一个多部分版本号，我将不得不解释或文档。 而且我不想使用SVN rev数字，因为这需要一些解释。
您需要在SVN之上使用一些发行脚本来实现这一点
我们使用一个简单的major.minor.julian_date语法。
哪里;
- 主要 – 首先发布是1，然后当我们介绍主要的新function或变化如此重大，他们不向后兼容增加这个数字。
- 轻微 – 主要里程碑版本。 对于生产推动的每个构build，这个数字都会增加
- julian_date – Julian Day的构build被推到QA。
在1/15推送到QA的第一个版本的例子是 – > 1.0.015
在3/4推送到生产的第一个版本的例子是 – > 1.1.063
这不是完美的，但是我们每天都会把版本推到QA上。
这里有一些好的信息：
何时更改文件/assembly版本
首先，文件版本和程序集版本不必相互重合。 我build议文件版本随每个版本而改变。 但是，不要为每个版本更改汇编版本，以便可以区分同一文件的两个版本之间的区别; 使用文件版本。 决定何时更改组件版本需要讨论一下构build的types：运输和非运输。
非发货版本一般而言，我build议在发货版本之间保留非发货组装版本。 这避免了由于版本不匹配导致的强烈命名的程序集加载问题。 有些人更喜欢使用发布者策略为每个构buildredirect新的程序集版本。 我build议不要这样做，但是，它不能避免所有的加载问题。 例如，如果合作伙伴x复制您的应用程序，他们可能不知道要安装发布者策略。 然后，你的应用程序将被打破，即使它在你的机器上工作得很好。
但是，如果在同一台机器上的不同应用程序需要绑定到不同版本的程序集，我build议给这些版本不同的程序集版本，以便每个应用程序都可以使用正确的程序，而无需使用LoadFrom / etc。
发货版本至于是否更改发行版本的版本是一个好主意，取决于您希望绑定如何为最终用户工作。 你想要这些构build是并排还是就地？ 这两个版本之间有很多变化吗？ 他们会打破一些客户？ 你是否在乎它打破了他们（或者你想强迫用户使用你的重要更新）？ 如果是的话，你应该考虑递增程序集版本。 但是，再次，考虑到这样做太多次可以抛弃用户的磁盘与过时的程序集。
当您更改组装版本时要将硬编码版本更改为新版本，build议在头文件中将版本设置为variables，并用variablesreplace源代码中的硬编码。 然后，在构build过程中运行一个预处理器来input正确的版本。 我build议在发货后立即更改版本，而不是之前的版本，以便有更多的时间来修复由于更改而引起的错误。
或者使用你的“思想”版本号逗号颠覆号.. zB：
1.0.101 //修订版101，发布
或1.0.101-090303 //发布date，我用这个
