Our product has a long history (12 years or so).
我们的产品历史悠久(12年左右)。
It's origins are in VB3 (Version 1) and later VB6 (Version 2). (Version numbers were a "dogs breakfast" and version control was a nightmare.
它的起源是VB3(版本1)和后来的VB6(版本2)。 (版本号是“狗早餐”,版本控制是一场噩梦。
I've been involved here for a couple of years now. We have Version 3 in development on the .Net platform but version 2 continues to be supported with periodic releases - about 3 or 4 per year.
我已经在这里参与了几年。我们在.Net平台上开发了版本3,但版本2继续得到定期版本的支持 - 每年约3或4个版本。
I introduced nightly automated builds back when I started and the version number of our product was 2.2.2. Everyone was planning on just releasing 2.2.3, but the automated build process and VB6's "interesting" 3 part numbering system, meant we need to make use of the third portion - build / revision number - which ever it is supposed to be.
我在开始时介绍了夜间自动化版本,我们的产品版本号是2.2.2。每个人都计划只发布2.2.3,但是自动构建过程和VB6的“有趣的”3部分编号系统,意味着我们需要使用第三部分 - 构建/修订号 - 这应该是它应该的。
So we released version 2.3 (with a build number of "whatever") and went to work on 2.4 (incrementing build numbers nightly), then 2.5, then 2.6 etc.
所以我们发布了2.3版本(内置版本为“无论什么”)并开始使用2.4(每晚递增构建数),然后是2.5,然后是2.6等。
The build number was hidden away from public view but available for support purposes even though we rarely release more than one build of a version - we have needed to patch occasionally though.
构建号远离公共视图,但可用于支持目的,即使我们很少发布多个版本的版本 - 我们偶尔需要修补。
Consistency ensured. Now we reach 2.9. We are about to move to 2.10 (Two point nine, up to Two point Ten). Unfortunately non-technical guys are reading this like a rational number (Two - point One). They can't understand why we don't just go to Version 3.0 - like counting. (The build number is only displayed on the "Help/About" screen for support purposes).
确保一致性。现在我们达到2.9。我们即将进入2.10(两点九,最多两点十)。不幸的是,非技术人员正在读这个像一个有理数的人(两点一)。他们无法理解为什么我们不只是去3.0版 - 就像计数一样。 (为了支持目的,内部版本号仅显示在“帮助/关于”屏幕上)。
I don't think a product (major number) upgrade is warranted especially due to the expectations this will set in the market place.
我不认为产品(主要数量)升级是有保证的,特别是由于市场预期会产生预期。
Is there a correct way to proceed here? (2.10 or 3.0 or something better - or does it even matter?)
有没有正确的方法在这里继续? (2.10或3.0或更好的东西 - 或者甚至更重要?)
(NB. I've gone to some lengths to ensure the version number now displays as 2.09, instead of 2.9 (on our web site, the product splash screen and various other public places etc), so that when we move to 2.10 it may make more sense, but this is potentially just as confusing because 2.09 is really a lower rational number than 2.8...)
(注意:我已经花了一些时间来确保版本号现在显示为2.09,而不是2.9(在我们的网站上,产品启动画面和各种其他公共场所等),所以当我们移动到2.10时它可能更有意义,但这可能同样令人困惑,因为2.09实际上是一个比2.8更低的有理数......)
See Also:
决定版本号
如何做版本号?
How do you know what version number to use?
你怎么知道使用什么版本号?
12 个解决方案
#1
Look at it as a chance for the non-technical guys to learn something ;-) Version numbers should be like chapter and section numbers in a book, they split the lifetime of your program into coherent and internally consistent blocks.
把它看作是非技术人员学习东西的机会;-)版本号应该像书中的章节和章节编号一样,它们将程序的生命周期分成连贯且内部一致的块。
#2
How you version your own software is up to you. There is no "right" or "wrong", apart from what's best after considering maintenance, release-management and customer-support points of view. The important thing is for you to control the versioning--that you understand it, that everyone who works with the product understands it, and that it doesn't cause problems later. There is no meaning to going from 2.9 to 2.10 as opposed to 3.0 except the meaning you give to it.
您如何对自己的软件进行版本控制取决于您。除了考虑维护,发布管理和客户支持观点之外的最佳选择之外,没有“正确”或“错误”。重要的是你要控制版本控制 - 你理解它,每个使用该产品的人都理解它,并且以后它不会引起问题。除了你给它的含义之外,没有任何意义从2.9到2.10而不是3.0。
#3
The other answers are only half right. Version numbers have the meaning you give them, but they also have the meaning others give them. Your own meaning really doesn't matter since you're not going to be there to correct your users. If they think that going from 2.9 to 3.0 is a huge jump, then that's how they'll take it. If they're afraid of using x.0 versions, then they won't. If they're used to odd numbered releases being alphas, then they won't use those.
其他答案只有一半是正确的。版本号具有您给出的含义,但它们也具有其他人给出的含义。你自己的意思真的没关系,因为你不会去那里纠正你的用户。如果他们认为从2.9升到3.0是一个巨大的跳跃,那么他们就会采取这种方式。如果他们害怕使用x.0版本,那么他们就不会。如果他们习惯于奇数编号的版本是alphas,那么他们就不会使用它们。
As much as I'd hate to say it, version numbers are a marketing tool. They say something to the user about the release, so you must take that into account when choosing your version numbers.
尽管我不愿意这样说,但版本号是一种营销工具。他们向用户说明了发布的内容,因此在选择版本号时必须考虑到这一点。
Problem is, version numbers mean different things to different people. There are some things you can predict. As I mentioned above, people will be suspect of x.0 releases. They'll expect big changes for 2.x to 3.x. If you want to try to play that came, go ahead.
问题是,版本号对不同的人意味着不同的东西。有些事情你可以预测。正如我上面提到的,人们会怀疑x.0版本。他们预计2.x到3.x会发生重大变化。如果你想尝试发挥它,请继续。
There are two essential attributes of version numbers. First, they must always go up. Second, they must sort easily. The first is obvious, but the second is often violated. Consider version 2.9 -> 2.10. Numerically speaking, 2.9 is greater than 2.10. You must consider them major/minor version numbers in order for it to sort correctly. From this stems the confusion as to whether 2.10 or 3.0 follows 2.9. Even if we know the sorting rules, it still seems wrong. For this reason I always pad my versions. 2.09 is followed by 2.10. It sorts correctly both as a number and as a dotted pair.
版本号有两个基本属性。首先,他们必须总是上升。其次,他们必须轻松排序。第一个是显而易见的,但第二个经常被违反。考虑版本2.9 - > 2.10。从数字上讲,2.9大于2.10。您必须将它们视为主要/次要版本号,以便正确排序。由此引发了关于2.10或3.0是否跟随2.9的混淆。即使我们知道排序规则,它似乎仍然是错误的。出于这个原因,我总是填写我的版本。 2.09之后是2.10。它可以正确排序为数字和虚线对。
That still leaves us with the user trying to divine meaning from the version number, like numerologists sifting through winning lottery numbers. You can try to play that game, or you can leave it. Why use a dotted pair at all? Use an integer. It's unambiguous. It sorts trivially. It gives no false meaning for the user to latch on to.
这仍然让我们的用户试图从版本号中划分意义,就像数字命理学家在筛选中奖彩票时那样。你可以尝试玩这个游戏,或者你可以离开它。为什么要使用虚线对?使用整数。这是毫不含糊的。它琐碎地分类。它没有给用户锁定的错误含义。
I can go one better. There is clear meaning you can give to a version number, something that is useful. There's a problem we have in the CPAN world of people not upgrading their modules because they're using version 1.03 and the latest is 1.07 and look, it's only .04 difference. Why bother upgrading? What it doesn't show is that there was four years between 1.03 and 1.07. Microsoft figured that out, that's why we buy Office 2009 instead of Office 12 (it can also bite you in the ass if you don't release often, who would want Windows 98 in 2001?) It's right there in the version number. "Widgets 2007" tells you maybe you should go look for an upgrade.
我可以更好一点。您可以为版本号提供明确的含义,这是有用的。我们在CPAN世界中存在一个问题,即人们没有升级他们的模块,因为他们使用的是版本1.03,而最新版本是1.07,看起来,它只有.04的区别。为什么要打扰升级呢?它没有显示的是,在1.03和1.07之间有四年。微软认为,这就是为什么我们购买Office 2009而不是Office 12(如果你不经常发布,它也可能会让你陷入困境,谁会在2001年想要Windows 98?)它就在版本号中。 “Widgets 2007”告诉你也许你应该去寻找升级。
I used to use ISO dates as versions. If you released today it would be version 20090309. If you had to release two in one day, tack the hour and minute on the end: 20090309.2051. It sorts easy. It always goes up. It conveys some unambiguous meaning to the user about the release. Here's an example.
我曾经使用ISO日期作为版本。如果您今天发布它将是版本20090309.如果您必须在一天内发布两个,请结束时间和分钟:20090309.2051。它很容易排序。它总是在上升。它向用户传达了一些关于发布的明确含义。这是一个例子。
I now use Semantic Versioning. It uses a dotted triple to convey three important pieces of information. Has the API been broken? Have features been added? Is this just a bug fix? The user must be aware that your project is using Semantic Versions, a disadvantage over ISO date versions. The advantage is the type of information it conveys and that it is well-defined.
我现在使用语义版本控制。它使用虚线三元组来传达三条重要的信息。 API被打破了吗?是否添加了功能?这只是一个bug修复?用户必须知道您的项目正在使用语义版本,这是ISO日期版本的缺点。优点是它传达的信息类型,并且定义明确。
#4
You could do 2.9.1 or even 2.10.1 but there are many projects that keep counting. 2.10, 2.11 12 13 etc.
您可以执行2.9.1甚至2.10.1但是有许多项目需要继续计算。 2.10,2.11 12 13等
#5
I would suggest to always use at least 3 components in your version numbers, and don't hide anything but the forth or further components. Stick to that convention everywhere, because it makes obvious to non-technical people that that can't be a rational number, it has to be something else (that is, a compound of three integers).
我建议在您的版本号中始终使用至少3个组件,并且不要隐藏除第四个或更多组件之外的任何组件。在任何地方都坚持这种惯例,因为非技术人员明白这不是一个有理数,它必须是别的东西(即三个整数的复合体)。
- 2.8.0
- 2.9.0
- 2.10.0
- 2.11.0
- ...
Also, in about dialogs, stick the build date (yyyy-mm-dd) near the version number. If the customer is confused with the version numbers, he/she can just compare the dates, that is far more intuitive for normal people.
此外,在大约对话框中,将构建日期(yyyy-mm-dd)粘贴在版本号附近。如果客户与版本号混淆,他/她可以只比较日期,这对普通人来说更直观。
#6
I think you pursued the correct approach by going towards 2.10. The primary purpose of version numbers should be the grouping of new features and development into definable released versions. If your numbering is getting in the way of this, you need a different numbering scheme.
我认为你通过走向2.10追求正确的方法。版本号的主要目的应该是将新功能分组并发展为可定义的发布版本。如果你的编号妨碍了这一点,你需要一个不同的编号方案。
#7
If 2.10 causes confusion then skip it and go to 2.11. Get ready for the same problem with 2.20 though :)
如果2.10引起混淆,则跳过它并转到2.11。准备好了2.20虽然:)同样的问题
#8
I recommend decoupling your marketing version from the internal versions of you DLLs and whatnot. They have different semantics.
我建议将您的营销版本与您的DLL的内部版本以及诸如此类的东西分离。它们有不同的语义。
#9
Wikipedia has very good article on software versioning
*有很多关于软件版本控制的文章
If you are working on long on-going project, sequence-based identifiers (like 1.0, 2.0 etc) don't scale.
如果您正在处理长期正在进行的项目,基于序列的标识符(如1.0,2.0等)不会扩展。
I personally like (and prefer) Ubuntu versioning scheme which is using year and month of release in its version. Ubuntu 8.04, for example, was released April 2008.
我个人喜欢(并且更喜欢)在其版本中使用年份和月份的Ubuntu版本控制方案。例如,Ubuntu 8.04于2008年4月发布。
#10
You should tell them to brand the version of the software in a way that is independent of the internal version number. For instance, iPhoto '09 is iPhoto version 8.x. Microsoft did the same thing.
您应该告诉他们以与内部版本号无关的方式标记软件版本。例如,iPhoto '09是iPhoto版本8.x.微软做了同样的事情。
Clearly, the major vendors have moved towards a branded version having to do with feature releases while allowing the developers to be freer with their version numbers. This satisfies everybody and the marketing guys will be especially happy because they get to come up with a whole new strategy for how to brand the software releases.
显然,主要供应商已经转向与功能发布有关的品牌版本,同时允许开发人员更*地使用他们的版本号。这让每个人都满意,营销人员会特别高兴,因为他们会为如何为软件版本打造一个全新的策略。
#11
Thanks - there are so many great answers here.
谢谢 - 这里有很多很棒的答案。
I'm having "accept an answer anxiety" - but I think it's probably right to take a bit from each answer.
我正在“接受一个回答焦虑” - 但我认为从每个答案中取一点可能是正确的。
Firstly, there is no right or wrong here. Secondly, numbering shouldn't get in the way of anything.
首先,这里没有对错。其次,编号不应妨碍任何事情。
Version numbering can be thought of like chapters and section numbers in a book - which will really help me explain to others, the way I'm thinking at least.
版本编号可以被认为是书中的章节和章节编号 - 这将真正帮助我向其他人解释,至少我在思考。
Separate / decouple the marketing versioning from the technical / development version numbering would solve everything...this is a longer term answer though.
将营销版本与技术/开发版本编号分开/分离将解决所有问题......但这是一个较长期的答案。
I'm sticking with 2.10 to follow 2.9 - and I'll battle on...and definitely investigate Ubuntu
我坚持使用2.10跟随2.9 - 我将继续战斗......并且肯定会调查Ubuntu
#12
I wouldn't use major version numbers to represent complete re-writes. A re-write is so infrequent, that for a lot of employees you'd just have to explain that version 1 was "before you worked here." If your product was called "Stack Overflow" then I'd just call the re-write "Stack Overflow" and the older one "Old Stack Overflow." That serves as a constant reminder to users of the old one that they need to migrate.
我不会使用主要版本号来表示完整的重写。重写非常罕见,对于很多员工来说,你只需要解释版本1是“在你工作之前”。如果你的产品被称为“堆栈溢出”,那么我只是调用重写“Stack Overflow”和旧的“Old Stack Overflow”。这可以不断提醒他们需要迁移的旧用户。
#1
Look at it as a chance for the non-technical guys to learn something ;-) Version numbers should be like chapter and section numbers in a book, they split the lifetime of your program into coherent and internally consistent blocks.
把它看作是非技术人员学习东西的机会;-)版本号应该像书中的章节和章节编号一样,它们将程序的生命周期分成连贯且内部一致的块。
#2
How you version your own software is up to you. There is no "right" or "wrong", apart from what's best after considering maintenance, release-management and customer-support points of view. The important thing is for you to control the versioning--that you understand it, that everyone who works with the product understands it, and that it doesn't cause problems later. There is no meaning to going from 2.9 to 2.10 as opposed to 3.0 except the meaning you give to it.
您如何对自己的软件进行版本控制取决于您。除了考虑维护,发布管理和客户支持观点之外的最佳选择之外,没有“正确”或“错误”。重要的是你要控制版本控制 - 你理解它,每个使用该产品的人都理解它,并且以后它不会引起问题。除了你给它的含义之外,没有任何意义从2.9到2.10而不是3.0。
#3
The other answers are only half right. Version numbers have the meaning you give them, but they also have the meaning others give them. Your own meaning really doesn't matter since you're not going to be there to correct your users. If they think that going from 2.9 to 3.0 is a huge jump, then that's how they'll take it. If they're afraid of using x.0 versions, then they won't. If they're used to odd numbered releases being alphas, then they won't use those.
其他答案只有一半是正确的。版本号具有您给出的含义,但它们也具有其他人给出的含义。你自己的意思真的没关系,因为你不会去那里纠正你的用户。如果他们认为从2.9升到3.0是一个巨大的跳跃,那么他们就会采取这种方式。如果他们害怕使用x.0版本,那么他们就不会。如果他们习惯于奇数编号的版本是alphas,那么他们就不会使用它们。
As much as I'd hate to say it, version numbers are a marketing tool. They say something to the user about the release, so you must take that into account when choosing your version numbers.
尽管我不愿意这样说,但版本号是一种营销工具。他们向用户说明了发布的内容,因此在选择版本号时必须考虑到这一点。
Problem is, version numbers mean different things to different people. There are some things you can predict. As I mentioned above, people will be suspect of x.0 releases. They'll expect big changes for 2.x to 3.x. If you want to try to play that came, go ahead.
问题是,版本号对不同的人意味着不同的东西。有些事情你可以预测。正如我上面提到的,人们会怀疑x.0版本。他们预计2.x到3.x会发生重大变化。如果你想尝试发挥它,请继续。
There are two essential attributes of version numbers. First, they must always go up. Second, they must sort easily. The first is obvious, but the second is often violated. Consider version 2.9 -> 2.10. Numerically speaking, 2.9 is greater than 2.10. You must consider them major/minor version numbers in order for it to sort correctly. From this stems the confusion as to whether 2.10 or 3.0 follows 2.9. Even if we know the sorting rules, it still seems wrong. For this reason I always pad my versions. 2.09 is followed by 2.10. It sorts correctly both as a number and as a dotted pair.
版本号有两个基本属性。首先,他们必须总是上升。其次,他们必须轻松排序。第一个是显而易见的,但第二个经常被违反。考虑版本2.9 - > 2.10。从数字上讲,2.9大于2.10。您必须将它们视为主要/次要版本号,以便正确排序。由此引发了关于2.10或3.0是否跟随2.9的混淆。即使我们知道排序规则,它似乎仍然是错误的。出于这个原因,我总是填写我的版本。 2.09之后是2.10。它可以正确排序为数字和虚线对。
That still leaves us with the user trying to divine meaning from the version number, like numerologists sifting through winning lottery numbers. You can try to play that game, or you can leave it. Why use a dotted pair at all? Use an integer. It's unambiguous. It sorts trivially. It gives no false meaning for the user to latch on to.
这仍然让我们的用户试图从版本号中划分意义,就像数字命理学家在筛选中奖彩票时那样。你可以尝试玩这个游戏,或者你可以离开它。为什么要使用虚线对?使用整数。这是毫不含糊的。它琐碎地分类。它没有给用户锁定的错误含义。
I can go one better. There is clear meaning you can give to a version number, something that is useful. There's a problem we have in the CPAN world of people not upgrading their modules because they're using version 1.03 and the latest is 1.07 and look, it's only .04 difference. Why bother upgrading? What it doesn't show is that there was four years between 1.03 and 1.07. Microsoft figured that out, that's why we buy Office 2009 instead of Office 12 (it can also bite you in the ass if you don't release often, who would want Windows 98 in 2001?) It's right there in the version number. "Widgets 2007" tells you maybe you should go look for an upgrade.
我可以更好一点。您可以为版本号提供明确的含义,这是有用的。我们在CPAN世界中存在一个问题,即人们没有升级他们的模块,因为他们使用的是版本1.03,而最新版本是1.07,看起来,它只有.04的区别。为什么要打扰升级呢?它没有显示的是,在1.03和1.07之间有四年。微软认为,这就是为什么我们购买Office 2009而不是Office 12(如果你不经常发布,它也可能会让你陷入困境,谁会在2001年想要Windows 98?)它就在版本号中。 “Widgets 2007”告诉你也许你应该去寻找升级。
I used to use ISO dates as versions. If you released today it would be version 20090309. If you had to release two in one day, tack the hour and minute on the end: 20090309.2051. It sorts easy. It always goes up. It conveys some unambiguous meaning to the user about the release. Here's an example.
我曾经使用ISO日期作为版本。如果您今天发布它将是版本20090309.如果您必须在一天内发布两个,请结束时间和分钟:20090309.2051。它很容易排序。它总是在上升。它向用户传达了一些关于发布的明确含义。这是一个例子。
I now use Semantic Versioning. It uses a dotted triple to convey three important pieces of information. Has the API been broken? Have features been added? Is this just a bug fix? The user must be aware that your project is using Semantic Versions, a disadvantage over ISO date versions. The advantage is the type of information it conveys and that it is well-defined.
我现在使用语义版本控制。它使用虚线三元组来传达三条重要的信息。 API被打破了吗?是否添加了功能?这只是一个bug修复?用户必须知道您的项目正在使用语义版本,这是ISO日期版本的缺点。优点是它传达的信息类型,并且定义明确。
#4
You could do 2.9.1 or even 2.10.1 but there are many projects that keep counting. 2.10, 2.11 12 13 etc.
您可以执行2.9.1甚至2.10.1但是有许多项目需要继续计算。 2.10,2.11 12 13等
#5
I would suggest to always use at least 3 components in your version numbers, and don't hide anything but the forth or further components. Stick to that convention everywhere, because it makes obvious to non-technical people that that can't be a rational number, it has to be something else (that is, a compound of three integers).
我建议在您的版本号中始终使用至少3个组件,并且不要隐藏除第四个或更多组件之外的任何组件。在任何地方都坚持这种惯例,因为非技术人员明白这不是一个有理数,它必须是别的东西(即三个整数的复合体)。
- 2.8.0
- 2.9.0
- 2.10.0
- 2.11.0
- ...
Also, in about dialogs, stick the build date (yyyy-mm-dd) near the version number. If the customer is confused with the version numbers, he/she can just compare the dates, that is far more intuitive for normal people.
此外,在大约对话框中,将构建日期(yyyy-mm-dd)粘贴在版本号附近。如果客户与版本号混淆,他/她可以只比较日期,这对普通人来说更直观。
#6
I think you pursued the correct approach by going towards 2.10. The primary purpose of version numbers should be the grouping of new features and development into definable released versions. If your numbering is getting in the way of this, you need a different numbering scheme.
我认为你通过走向2.10追求正确的方法。版本号的主要目的应该是将新功能分组并发展为可定义的发布版本。如果你的编号妨碍了这一点,你需要一个不同的编号方案。
#7
If 2.10 causes confusion then skip it and go to 2.11. Get ready for the same problem with 2.20 though :)
如果2.10引起混淆,则跳过它并转到2.11。准备好了2.20虽然:)同样的问题
#8
I recommend decoupling your marketing version from the internal versions of you DLLs and whatnot. They have different semantics.
我建议将您的营销版本与您的DLL的内部版本以及诸如此类的东西分离。它们有不同的语义。
#9
Wikipedia has very good article on software versioning
*有很多关于软件版本控制的文章
If you are working on long on-going project, sequence-based identifiers (like 1.0, 2.0 etc) don't scale.
如果您正在处理长期正在进行的项目,基于序列的标识符(如1.0,2.0等)不会扩展。
I personally like (and prefer) Ubuntu versioning scheme which is using year and month of release in its version. Ubuntu 8.04, for example, was released April 2008.
我个人喜欢(并且更喜欢)在其版本中使用年份和月份的Ubuntu版本控制方案。例如,Ubuntu 8.04于2008年4月发布。
#10
You should tell them to brand the version of the software in a way that is independent of the internal version number. For instance, iPhoto '09 is iPhoto version 8.x. Microsoft did the same thing.
您应该告诉他们以与内部版本号无关的方式标记软件版本。例如,iPhoto '09是iPhoto版本8.x.微软做了同样的事情。
Clearly, the major vendors have moved towards a branded version having to do with feature releases while allowing the developers to be freer with their version numbers. This satisfies everybody and the marketing guys will be especially happy because they get to come up with a whole new strategy for how to brand the software releases.
显然,主要供应商已经转向与功能发布有关的品牌版本,同时允许开发人员更*地使用他们的版本号。这让每个人都满意,营销人员会特别高兴,因为他们会为如何为软件版本打造一个全新的策略。
#11
Thanks - there are so many great answers here.
谢谢 - 这里有很多很棒的答案。
I'm having "accept an answer anxiety" - but I think it's probably right to take a bit from each answer.
我正在“接受一个回答焦虑” - 但我认为从每个答案中取一点可能是正确的。
Firstly, there is no right or wrong here. Secondly, numbering shouldn't get in the way of anything.
首先,这里没有对错。其次,编号不应妨碍任何事情。
Version numbering can be thought of like chapters and section numbers in a book - which will really help me explain to others, the way I'm thinking at least.
版本编号可以被认为是书中的章节和章节编号 - 这将真正帮助我向其他人解释,至少我在思考。
Separate / decouple the marketing versioning from the technical / development version numbering would solve everything...this is a longer term answer though.
将营销版本与技术/开发版本编号分开/分离将解决所有问题......但这是一个较长期的答案。
I'm sticking with 2.10 to follow 2.9 - and I'll battle on...and definitely investigate Ubuntu
我坚持使用2.10跟随2.9 - 我将继续战斗......并且肯定会调查Ubuntu
#12
I wouldn't use major version numbers to represent complete re-writes. A re-write is so infrequent, that for a lot of employees you'd just have to explain that version 1 was "before you worked here." If your product was called "Stack Overflow" then I'd just call the re-write "Stack Overflow" and the older one "Old Stack Overflow." That serves as a constant reminder to users of the old one that they need to migrate.
我不会使用主要版本号来表示完整的重写。重写非常罕见,对于很多员工来说,你只需要解释版本1是“在你工作之前”。如果你的产品被称为“堆栈溢出”,那么我只是调用重写“Stack Overflow”和旧的“Old Stack Overflow”。这可以不断提醒他们需要迁移的旧用户。