我们的产品历史悠久（12年左右）。
它的起源是VB3（版本1）和后来的VB6（版本2）。 （版本号是“狗早餐”，版本控制是一场噩梦。
我已经在这里参与了几年。我们在.Net平台上开发了第3版，但第2版继续得到定期版本的支持 - 每年大约3或4个。
我在开始时介绍了夜间自动构建，我们的产品版本号是2.2.2。每个人都计划只发布2.2.3，但自动构建过程和VB6的“有趣”3部分编号系统，意味着我们需要使用第三部分 - 构建/修订号 - 这应该是它应该的。
所以我们发布了2.3版（内置版本为“无论什么”）并开始使用2.4（每晚增加内部版本号），然后是2.5，然后是2.6等。
内部版本号远离公众视图，但可用于支持目的，即使我们很少发布多个版本的版本 - 我们偶尔需要修补。
确保一致性。现在我们达到2.9。我们即将进入2.10（两点九，最多两点十）。不幸的是，非技术人员正在读这个像一个有理数的人（两点一）。他们无法理解为什么我们不只是去3.0版 - 就像计数一样。 （为了支持起见，内部版本号仅显示在“帮助/关于”屏幕上。）
我不认为产品（主要数量）升级是有保证的，特别是由于市场预期会产生预期。
有没有正确的方法在这里继续？ （2.10或3.0或更好的东西 - 或者甚至更重要？）
（注意：我已经花了一些时间来确保版本号现在显示为2.09，而不是2.9（在我们的网站上，产品启动画面和各种其他公共场所等），所以当我们转向2.10它可能更有意义，但这可能同样令人困惑，因为2.09实际上是一个比2.8更低的有理数......）
另见：
答案 0 :(得分：9)
将其视为非技术人员学习某些东西的机会;-)版本号应该像书中的章节和章节编号一样，它们将程序的生命周期分成连贯且内部一致的块。
答案 1 :(得分：6)
您自己软件的版本由您决定。除了考虑维护，发布管理和客户支持观点之后的最佳选择之外，没有“正确”或“错误”。重要的是你要控制版本控制 - 你理解它，每个使用该产品的人都理解它，并且以后不会引起问题。除了你赋予它的含义之外，没有任何意义从2.9到2.10而不是3.0。
答案 2 :(得分：6)
其他答案只有一半是正确的。版本号具有您给出的含义，但它们也具有其他人给出的含义。你自己的意思真的没关系，因为你不会去那里纠正你的用户。如果他们认为从2.9升到3.0是一个巨大的跳跃，那么他们就会采取这种方式。如果他们害怕使用x.0版本，那么他们就不会。如果他们习惯于奇数编号的版本是alphas，那么他们就不会使用那些。
尽管我不愿意这么说，版本号是一种营销工具。他们向用户说明了发布的内容，因此在选择版本号时必须考虑到这一点。
问题是，版本号对不同的人意味着不同的东西。有些事情你可以预测。正如我上面提到的，人们会怀疑x.0版本。他们预计2.x到3.x会发生重大变化。如果您想尝试播放，请继续。
版本号有两个基本属性。首先，他们必须总是上升。其次，他们必须轻松排序。第一个是显而易见的，但第二个经常被违反。考虑版本2.9 - ＆gt; 2.10。从数字上讲，2.9大于2.10。您必须将它们视为主要/次要版本号，以便正确排序。由此引发了关于2.10或3.0是否跟随2.9的混淆。即使我们知道排序规则，它似乎仍然是错误的。出于这个原因，我总是填写我的版本。 2.09之后是2.10。它可以正确排序为数字和虚线对。
这仍然让我们的用户试图从版本号中划分意义，就像数字命理员筛选中奖彩票一样。你可以尝试玩这个游戏，或者你可以离开它。为什么要使用虚线对？使用整数。这是毫不含糊的。它琐碎地分类。它没有给用户锁定的错误含义。
我可以更好一点。你可以给版本号提供明确的含义，这是有用的。我们在CPAN世界中存在一个问题，即人们没有升级他们的模块，因为他们使用的是版本1.03而最新版本是1.07，看起来，它只有.04的区别。为什么要打扰升级呢？它没有显示的是，在1.03和1.07之间有四年。微软认为，这就是为什么我们购买Office 2009而不是Office 12（如果你不经常发布，它也可能会惹恼你，谁会想要在2001年推出Windows 98？）它就在版本号中。 “Widgets 2007”告诉你，也许你应该去寻找升级。
我曾经使用ISO日期作为版本。如果您今天发布它将是版本20090309.如果您必须在一天内发布两个，请结束时间和分钟：20090309.2051。它很容易排序。它总是上升。它向用户传达了一些关于发布的明确含义。 Here's an example
我现在使用Semantic Versioning。它使用虚线三元组来传达三条重要的信息。 API被打破了吗？是否添加了功能？这只是一个bug修复？用户必须知道您的项目正在使用语义版本，这是ISO日期版本的缺点。优点是它传达的信息类型，并且定义明确。
答案 3 :(得分：4)
你可以做2.9.1甚至2.10.1但是有很多项目都在计算。 2.10,2.11 12 13等。
答案 4 :(得分：4)
我建议在您的版本号中始终使用至少3个组件，除了第四个或更多组件外，不要隐藏任何内容。在任何地方都坚持这种惯例，因为对于非技术人员而言，这显然不是一个有理数，它必须是别的东西（即三个整数的复合体）。
此外，在关于对话框中，将构建日期（yyyy-mm-dd）粘贴在版本号附近。如果客户对版本号感到困惑，他/她可以比较日期，对于普通人来说，远更直观。
答案 5 :(得分：3)
我认为你通过走向2.10来追求正确的方法。版本号的主要目的应该是将新功能分组并发展为可定义的发布版本。如果你的编号受到影响，你需要一个不同的编号方案。
答案 6 :(得分：3)
如果2.10导致混淆，则跳过它并转到2.11。准备好了2.20但同样的问题：）
答案 7 :(得分：2)
我建议将您的营销版本与您的DLL的内部版本以及诸如此类的内容解耦。它们有不同的语义。
答案 8 :(得分：1)
维基百科有very good article on software versioning
如果您正在进行长期正在进行的项目，基于序列的标识符（如1.0,2.0等）不会扩展。
我个人喜欢（并且更喜欢）在其版本中使用年份和月份的Ubuntu版本控制方案。例如，Ubuntu 8.04于2008年4月发布。
答案 9 :(得分：1)
您应告诉他们以与内部版本号无关的方式标记软件版本。例如，iPhoto '09是iPhoto版本8.x.微软做了同样的事情。
显然，主要供应商已经转向与功能发布有关的品牌版本，同时允许开发人员更自由地使用他们的版本号。这让每个人都满意，营销人员会特别高兴，因为他们会为如何为软件版本打造一个全新的策略。
答案 10 :(得分：0)
谢谢 - 这里有很多很棒的答案。
我正在“接受一个回答焦虑” - 但我认为从每个答案中略过一点可能是正确的。
首先，这里没有对错。 其次，编号不应妨碍任何事情。
版本编号可以被认为是书中的章节和章节编号 - 这将真正帮助我向其他人解释，至少我在思考的方式。
将营销版本与技术/开发版本编号分开/解耦将解决所有问题......但这是一个较长期的答案。
我坚持使用2.10跟随2.9 - 我将继续战斗......并且肯定会调查Ubuntu
答案 11 :(得分：0)
我不会使用主要版本号来表示完整的重写。重写非常罕见，对于很多员工来说，你只需要解释第1版就是“在你工作之前”。如果您的产品被称为“堆栈溢出”，那么我只是调用重写“Stack Overflow”和旧的“Old Stack Overflow”。这可以不断提醒他们需要迁移的旧用户。