I'm starting to like the Year.Release[.Build] convention that some apps (e.g. Perforce) use. Basically it just says the year in which you release, and the sequence within that year. So 2008.1 would be the first version, and if you released another a months or three later, it would go to 2008.2.
The advantage of this scheme is there is no implied "magnitude" of release, where you get into arguments about whether a feature is major enough to warrant a major version increment or not.
An optional extra is to tag on the build number, but that tends to be for internal purposes only (e.g. added to the EXE/DLL so you can inspect the file and ensure the right build is there).
In my opinion, almost any release number scheme can be made to work more or less sanely. The system I work on uses version numbers such as 11.50.UC3, where the U indicates 32-bit Unix, and the C3 is a minor revision (fix pack) number; other letters are used for other platform types. (I'd not recommend this scheme, but it works.)
There are a few golden rules which have not so far been stated, but which are implicit in what people have discussed.
Do not release the same version twice - once version 1.0.0 is released to anyone, it can never be re-released.
Release numbers should increase monotonically. That is, the code in version 1.0.1 or 1.1.0 or 2.0.0 should always be later than version 1.0.0, 1.0.9, or 1.4.3 (respectively).
Now, in practice, people do have to release fixes for older versions while newer versions are available -- see GCC, for example:
GCC 3.4.6 was released after 4.0.0, 4.1.0 (and AFAICR 4.2.0), but it continues the functionality of GCC 3.4.x rather than adding the extra features added to GCC 4.x.
So, you have to build your version numbering scheme carefully.
One other point which I firmly believe in:
The release version number is unrelated to the CM (VCS) system version numbering, except for trivial programs. Any serious piece of software with more than one main source file will have a version number unrelated to the version of any single file.
With SVN, you could use the SVN version number - but probably wouldn't as it changes too unpredictably.
For the stuff I work with, the version number is a purely political decision.
Incidentally, I know of software that went through releases from version 1.00 through 9.53, but that then changed to 2.80. That was a gross mistake - dictated by marketing. Granted, version 4.x of the software is/was obsolete, so it didn't immediately make for confusion, but version 5.x of the software is still in use and sold, and the revisions have already reached 3.50. I'm very worried about what my code that has to work with both the 5.x (old style) and 5.x (new style) is going to do when the inevitable conflict occurs. I guess I have to hope that they will dilly-dally on changing to 5.x until the old 5.x really is dead -- but I'm not optimistic. I also use an artificial version number, such as 9.60, to represent the 3.50 code, so that I can do sane if VERSION > 900 testing, rather than having to do: if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400), where I represent version 9.00 by 900. And then there's the significant change introduced in version 3.00.xC3 -- my scheme fails to detect changes at the minor release level...grumble...grumble...
我通常使用 D 作为构建计数器（编译器自动递增） 每次将构建发布到“公共”时，我都会增加 C （并非每个构建都会发布） A和B用作主/次版本号并手动更改。
I usually use D as a build counter (automatic increment by compiler) I increment C every time a build is released to "public" (not every build is released) A and B are used as major/minor version number and changed manually.
营销：根据向客户提供的“新”或“有用”功能数量来增加版本。 您还可以将版本号与更新策略联系起来...对 A 的更改要求用户购买升级许可证，而其他更改则不需要。
我认为最重要的是找到适合您和您的客户的模型。 我见过一些情况，偶数版本是公开版本，奇数版本被视为测试版或开发版本。 我见过一些产品完全忽略了 C 和 D。
然后是 Microsoft 的示例，其中对 .Net Framework 版本号的唯一合理解释是涉及营销。
I think there are two ways to answer this question, and they are not entirely complimentary.
Technical: Increment versions based on technical tasks. Example: D is build number, C is Iteration, B is a minor release, A is a major release. Defining minor and major releases is really subjective, but could be related things like changes to underlying architecture.
Marketing: Increment versions based on how many "new" or "useful" features are being provided to your customers. You may also tie the version numbers to an update policy...Changes to A require the user to purchase an upgrade license, whereas other changes do not.
The bottom line, I think, is finding a model that works for you and your customers. I've seen some cases where even versions are public releases, and odd versions are considered beta, or dev releases. I've seen some products which ignore C and D all together.
Then there is the example from Micrsoft, where the only rational explanation to the version numbers for the .Net Framework is that Marketing was involved.
People tend to want to make this much harder than it really needs to be. If your product has only a single long-lived branch, just name successive versions by their build number. If you've got some kind of "minor bug fixes are free, but you have to pay for major new versions", then use 1.0, 1.1 ... 1.n, 2.0, 2.1... etc.
If you can't immediately figure out what the A,B,C, and D in your example are, then you obviously don't need them.
A good and non-technical scheme just uses the build date in this format:
YYYY.MM.DD.BuildNumber
Where BuildNumber is either a continuous number (changelist) or just starts over at 1 each day.
Examples: 2008.03.24.1 or 2008.03.24.14503
This is mainly for internal releases, public releases would see the version printed as 2008.03 if you don't release more often than once a month. Maintenance releases get flagged as 2008.03a 2008.03b and so on. They should rarely go past "c" but if it does it's a good indicator you need better QA and/or testing procedures.
Version fields that are commonly seen by the user should be printed in a friendly "March 2008" format, reserve the more technical info in the About dialog or log files.
Biggest disadvantage: just compiling the same code on another day might change the version number. But you can avoid this by using the version control changelist as last number and checking against that to determine if the date needs to be changed as well.
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
V (version) changes are a major rewrite R (revision) changes are significant new features or bug fixes M (modification) changes are minor bux fixes (typos, etc)
I sometimes use an SVN commit number on the end too.
I like Year.Month.Day. So, v2009.6.8 would be the "version" of this post. It is impossible to duplicate (reasonably) and it very clear when something is a newer release. You could also drop the decimals and make it v20090608.
In the case of a library, the version number tells you about the level of compatibility between two releases, and thus how difficult an upgrade will be.
A bug fix release needs to preserve binary, source, and serialization compatibility.
Minor releases mean different things to different projects, but usually they don't need to preserve source compatibility.
For the past six major versions, we've used M.0.m.b where M is the major version, m is the minor version, and b is the build number. So released versions included 6.0.2, 7.0.1, ..., up to 11.0.0. Don't ask why the second number is always 0; I've asked a number of times and nobody really knows. We haven't had a non-zero there since 5.5 was released in 1996.
发布评论
评论（15）
我开始喜欢一些应用程序（例如 Perforce）使用的 Year.Release[.Build] 约定。 基本上它只是说你发布的年份，以及当年的顺序。 因此，2008.1 将是第一个版本，如果您在一三个月后发布另一个版本，它将变为 2008.2。
此方案的优点是没有隐含的发布“幅度”，您会争论某个功能是否足够重要以保证主要版本增量。
一个可选的额外功能是标记内部版本号，但这往往仅用于内部目的（例如添加到 EXE/DLL，以便您可以检查文件并确保存在正确的内部版本）。
I'm starting to like the Year.Release[.Build] convention that some apps (e.g. Perforce) use. Basically it just says the year in which you release, and the sequence within that year. So 2008.1 would be the first version, and if you released another a months or three later, it would go to 2008.2.
The advantage of this scheme is there is no implied "magnitude" of release, where you get into arguments about whether a feature is major enough to warrant a major version increment or not.
An optional extra is to tag on the build number, but that tends to be for internal purposes only (e.g. added to the EXE/DLL so you can inspect the file and ensure the right build is there).
在我看来，几乎任何版本号方案都可以或多或少地正常工作。 我工作的系统使用版本号，例如 11.50.UC3，其中 U 表示 32 位 Unix，C3 是次要修订（修订包）号； 其他字母用于其他平台类型。 （我不推荐这个方案，但它是有效的。）
有一些黄金规则到目前为止尚未阐明，但隐含在人们所讨论的内容中。
现在，在实践中，人们确实必须在有新版本可用时发布旧版本的修复程序 - 请参阅 GCC，例如：
因此，您必须仔细构建版本编号方案。
我坚信的另一点是：
对于 SVN，您可以使用 SVN 版本号 - 但可能不会，因为它的变化太不可预测。
对于我使用的东西，版本号纯粹是一个政治决定。
顺便说一句，我知道有一些软件的版本从 1.00 到 9.53，但后来变成了 2.80。 这是一个严重的错误——由营销决定。 诚然，该软件的 4.x 版本已经过时，因此并没有立即造成混乱，但该软件的 5.x 版本仍在使用和销售，并且修订版已经达到 3.50。 我非常担心当不可避免的冲突发生时，我的代码必须与 5.x（旧样式）和 5.x（新样式）一起工作。 我想我必须希望他们会磨磨蹭蹭地改变到 5.x，直到旧的 5.x 真的死了——但我并不乐观。 我还使用人工版本号（例如 9.60）来表示 3.50 代码，这样我就可以执行 sane
if VERSION > > 。 900测试，而不是必须执行：if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400)，其中我代表版本 9.00 900。然后是版本 3.00.xC3 中引入的重大更改 - 我的方案无法检测次要版本级别的更改...抱怨...抱怨...NB：Eric Raymond提供软件发布实践指南，包括（链接的）部分关于命名（编号）版本。
In my opinion, almost any release number scheme can be made to work more or less sanely. The system I work on uses version numbers such as 11.50.UC3, where the U indicates 32-bit Unix, and the C3 is a minor revision (fix pack) number; other letters are used for other platform types. (I'd not recommend this scheme, but it works.)
There are a few golden rules which have not so far been stated, but which are implicit in what people have discussed.
Now, in practice, people do have to release fixes for older versions while newer versions are available -- see GCC, for example:
So, you have to build your version numbering scheme carefully.
One other point which I firmly believe in:
With SVN, you could use the SVN version number - but probably wouldn't as it changes too unpredictably.
For the stuff I work with, the version number is a purely political decision.
Incidentally, I know of software that went through releases from version 1.00 through 9.53, but that then changed to 2.80. That was a gross mistake - dictated by marketing. Granted, version 4.x of the software is/was obsolete, so it didn't immediately make for confusion, but version 5.x of the software is still in use and sold, and the revisions have already reached 3.50. I'm very worried about what my code that has to work with both the 5.x (old style) and 5.x (new style) is going to do when the inevitable conflict occurs. I guess I have to hope that they will dilly-dally on changing to 5.x until the old 5.x really is dead -- but I'm not optimistic. I also use an artificial version number, such as 9.60, to represent the 3.50 code, so that I can do sane
if VERSION > 900testing, rather than having to do:if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400), where I represent version 9.00 by 900. And then there's the significant change introduced in version 3.00.xC3 -- my scheme fails to detect changes at the minor release level...grumble...grumble...NB: Eric Raymond provides Software Release Practice HOWTO including the (linked) section on naming (numbering) releases.
我通常使用 D 作为构建计数器（编译器自动递增）
每次将构建发布到“公共”时，我都会增加 C （并非每个构建都会发布）
A和B用作主/次版本号并手动更改。
I usually use D as a build counter (automatic increment by compiler)
I increment C every time a build is released to "public" (not every build is released)
A and B are used as major/minor version number and changed manually.
我认为有两种方法可以回答这个问题，而且它们并不完全是互补的。
我认为最重要的是找到适合您和您的客户的模型。 我见过一些情况，偶数版本是公开版本，奇数版本被视为测试版或开发版本。 我见过一些产品完全忽略了 C 和 D。
然后是 Microsoft 的示例，其中对 .Net Framework 版本号的唯一合理解释是涉及营销。
I think there are two ways to answer this question, and they are not entirely complimentary.
The bottom line, I think, is finding a model that works for you and your customers. I've seen some cases where even versions are public releases, and odd versions are considered beta, or dev releases. I've seen some products which ignore C and D all together.
Then there is the example from Micrsoft, where the only rational explanation to the version numbers for the .Net Framework is that Marketing was involved.
我们的政策：
增加功能或
界面。
增加功能或
界面。
破坏接口。
构建不改变
界面。
Our policy:
additions in functionality or
interface.
additions in functionality or
interface.
break the interface.
build that do not change the
interface.
人们往往想让事情变得比实际需要的更加困难。 如果您的产品只有一个长期分支，只需按版本号命名连续版本即可。 如果你有某种“小错误修复是免费的，但你必须为主要新版本付费”，那么使用 1.0、1.1 ... 1.n、2.0、2.1 ... 等等。
如果可以的话如果你不能立即弄清楚示例中的 A、B、C 和 D 是什么，那么你显然不需要它们。
People tend to want to make this much harder than it really needs to be. If your product has only a single long-lived branch, just name successive versions by their build number. If you've got some kind of "minor bug fixes are free, but you have to pay for major new versions", then use 1.0, 1.1 ... 1.n, 2.0, 2.1... etc.
If you can't immediately figure out what the A,B,C, and D in your example are, then you obviously don't need them.
我对版本号的唯一用途是让客户可以告诉我他们正在使用版本 2.5.1.0 或其他版本。
我唯一的规则是尽量减少报告该数字时的错误：所有四个数字都必须仅为 1 位数。
可以，但
不是。 客户可能会将这两个数字（至少口头上）报告为“一一二三”。
自动递增的内部版本号通常会产生这样的版本号，
这也没有真正的帮助。
The only use I have ever made of the version number was so that a customer could tell me they're using version 2.5.1.0 or whatever.
My only rule is designed to minimize mistakes in reporting that number: all four numbers have to be 1 digit only.
is ok, but
is not. Customers are likely to report both numbers (verbally, at least) as "one-one-two-three".
Auto-incrementing build numbers often results in version numbers like
which doesn't really help, either.
一个好的非技术方案只需使用以下格式的构建日期：
YYYY.MM.DD.BuildNumber
其中 BuildNumber 是连续数字（更改列表）或每天从 1 开始。
示例：2008.03.24.1 或 2008.03.24.14503
这主要用于内部版本，如果您发布的频率不超过每月一次，公开版本将看到打印为 2008.03 的版本。 维护版本被标记为 2008.03a 2008.03b 等等。 它们很少会超过“c”，但如果确实如此，则表明您需要更好的质量保证和/或测试程序。
用户常见的版本字段应以友好的“2008 年 3 月”格式打印，在“关于”对话框或日志文件中保留更多技术信息。
最大的缺点：改天编译相同的代码可能会改变版本号。 但是您可以通过使用版本控制更改列表作为最后一个数字并检查该列表以确定日期是否也需要更改来避免这种情况。
A good and non-technical scheme just uses the build date in this format:
YYYY.MM.DD.BuildNumber
Where BuildNumber is either a continuous number (changelist) or just starts over at 1 each day.
Examples: 2008.03.24.1 or 2008.03.24.14503
This is mainly for internal releases, public releases would see the version printed as 2008.03 if you don't release more often than once a month. Maintenance releases get flagged as 2008.03a 2008.03b and so on. They should rarely go past "c" but if it does it's a good indicator you need better QA and/or testing procedures.
Version fields that are commonly seen by the user should be printed in a friendly "March 2008" format, reserve the more technical info in the About dialog or log files.
Biggest disadvantage: just compiling the same code on another day might change the version number. But you can avoid this by using the version control changelist as last number and checking against that to determine if the date needs to be changed as well.
在 github 世界中，遵循 Tom Preston-Werner 的“semver”版本号规范已经变得很流行。
来自 http://semver.org/ ：
In the github world, it has become popular to follow Tom Preston-Werner's "semver" spec for version numbers.
From http://semver.org/ :
我使用 VRM，例如 2.5.1
V（版本）更改是一次重大重写
R（修订版）更改是重要的新功能或错误修复
M（修改）更改是次要的 bux 修复（拼写错误等），
我有时也会在末尾使用 SVN 提交号。
I use V.R.M e.g. 2.5.1
V (version) changes are a major rewrite
R (revision) changes are significant new features or bug fixes
M (modification) changes are minor bux fixes (typos, etc)
I sometimes use an SVN commit number on the end too.
归根结底，这一切都是非常主观的，完全取决于你自己/你的团队。
看看所有的答案就知道了——全都非常不同。
我个人使用
Major.Minor.*.*- Visual Studio 自动填写修订版/内部版本号。 我工作的地方也用这个。Its all really subjective at the end of the day and simply up to yourself/your team.
Just take a look at all the answers already - all very different.
Personally I use
Major.Minor.*.*- Where Visual Studio fills in the revison/build number automatically. This is used where I work too.我喜欢年.月.日。因此，v2009.6.8 将是这篇文章的“版本”。 它是不可能（合理地）复制的，并且当某些东西是较新的版本时它非常清楚。 您还可以去掉小数点并将其设为 v20090608。
I like Year.Month.Day. So, v2009.6.8 would be the "version" of this post. It is impossible to duplicate (reasonably) and it very clear when something is a newer release. You could also drop the decimals and make it v20090608.
对于库，版本号告诉您两个版本之间的兼容性级别，以及升级的难度。
错误修复版本需要保留二进制、源代码和序列化兼容性。
次要版本对于不同的项目意味着不同的事情，但通常它们不需要保留源兼容性。
主要版本号可以打破所有三种形式。
我在此处写了更多关于其基本原理的内容。
In the case of a library, the version number tells you about the level of compatibility between two releases, and thus how difficult an upgrade will be.
A bug fix release needs to preserve binary, source, and serialization compatibility.
Minor releases mean different things to different projects, but usually they don't need to preserve source compatibility.
Major version numbers can break all three forms.
I wrote more about the rationale here.
对于内部开发，我们使用以下格式。
例如，如果我今天发布应用程序＃15，并且这是本月的第三次更新，那么我的版本＃将是
完全非标准的，但它对我们有用。
For in-house development, we use the following format.
For example, if I'm releasing application # 15 today, and it's the third update this month, then my version # will be
It's totally non-standard, but it is useful for us.
对于过去的六个主要版本，我们使用了 M.0.mb，其中 M 是主要版本，m 是次要版本，b 是内部版本号。 因此发布的版本包括 6.0.2、7.0.1、...、直到 11.0.0。 不要问为什么第二个数字总是0； 我问过很多次了，没有人真正知道。 自 1996 年发布 5.5 以来，我们还没有出现过非零值。
For the past six major versions, we've used M.0.m.b where M is the major version, m is the minor version, and b is the build number. So released versions included 6.0.2, 7.0.1, ..., up to 11.0.0. Don't ask why the second number is always 0; I've asked a number of times and nobody really knows. We haven't had a non-zero there since 5.5 was released in 1996.