A release candidate Git v1.9-rc2 is now available for testing at the usual places.
I've heard rumours that various third-party tools do not like the two-digit version numbers (e.g. "Git 2.0") and started barfing left and right when the users install v1.9-rc1.
While it is tempting to laugh at them for their sloppy assumption, I am also practical and
do not mind calling the upcoming release v1.9.0 to help them.
If we go that route (and I am inclined to go that route at this moment), the versioning scheme will be:
The next release candidate will be v1.9.0-rc3, not v1.9-rc3;
The first maintenance release for v1.9.0 will be v1.9.1 (and Nth one be v1.9.N); and
The feature release after v1.9.0 will be either v1.10.0 or v2.0.0, depending on how big the feature jump we are looking at.
At our company, we are using four token versioning concept. It's something like a.b.c.d kind:
(major).(feature).(revision).(bug/refactoring)
It's related with issue types which we use in our development life cycle. We can track what has done or changed between two following versions at a glance. By comparing two following version numbers you can identify number and types of issues done.
For more information, full documentation is here.
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.4.2.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]
Even i faced this problem with defining the version number while developing with CRM, since i wanted to deploy the same build across all the systems. I found a way to resolve it with System value + Manual + randoms.
The version information for an assembly consists of four values:
Major Version . Minor Version . Build Number . Revision
Which makes the initial Version 1.0.0.0 by default. To make more sense i replace it with
TFS Release . TFS Sprint . Change Number . Incremented build number
Suppose in your TFS a single release consists 30 sprints and after that the release becomes 2, so the values for the first release will be:
TFS Release : 1
If the current sprint is 4, the TFS Sprint will have
TFS Sprint : 4
Now the third part is managed by the developer, for a initial version we can have 0 which can be incremented +1 for each ChangeRequest or BugFix.
Although for every bugfix there might be a change in code, so it represents the code change as default. But to more more sense you can have the odd number to represent the change and even number to represent the bugfix.
The last part was the default number, thankfully .Net allows us to put * to put a default build number. It keeps on increment with every compile/build which provides a signature stamp, if someone else rebuilds it changes.
How to Implement:
Open the AssemblyInfo.cs in the Properties folder and Comment the AssemblyFileVersion, this will make the AssemblyFileVersion & AssemblyVersion same.
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.4.2.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]
So the final version will come out as: 1.4.2.4512 or something
The benefits of this approach is that you can track the Task for which the code is generated. Just by looking at the version number i can say, "Hey its the release 1 for sprint 4 and with some code change.
I'm "missing" several minor versions, how do you guys handle that situation?
You're not missing versions. It's perfectly acceptable to… (see next answer)
Which is a good starting version number
Depends if people are using your code in production. If it's already used in production jump straight to v1.0.0. But since you said your code is alpha, beta, or rc (release candidate) quality but you're planning to move to production quickly consider starting with v1.0.0-[alpha].N where [alpha] is the software grade and N is a build number or other enumerable value.
Is it ok to make numbers above 10? like v1.25 or v2.2.30?
That's the idea. Lexicographical sorting may not work but that's okay.
发布评论
评论（4）
版本编号策略有时可能有点疯狂（请参阅版本号和 JSR277，或 Oracle，及其 Oracle Database 11g 第 2 版：
11.2.0.1.0。另请参阅软件版本控制很荒谬）。
但您可以首先查看Eclipse 版本号策略作为一个好的开始。
如果您确实认为需要超过三位数，请参阅此 VRMF 维护流交付车辆术语解释也很有趣，但对于 1.0 后的软件程序更是如此，其中修复包和临时修复是有序的。
“已发货”：
1.0.0也称为“
1.oh-oh”版本。至少，它就在那里，您可以开始获取反馈并快速迭代。如果主要功能仍然缺失，那么
0.x；1.0.0如果有主要功能。是的，但我想说的是，仅适用于生命周期超过几年（通常是十年）的大型项目，
请注意“正确”（同时在 语义版本控制 2.0.0）也可以通过更实用的因素来指导：
请参阅 Git 1.9 公告（2014 年 1 月）：
2019 年 2 月更新：semver 本身即将演变（再次，在 semver2 之后）。
请参阅“SemVer 的下一步”和
semver/semver/CONTRIBUTING。Version numbering policies can be a bit crazy at times (see Version numbers and JSR277, or Oracle, with its Oracle Database 11g Release 2:
11.2.0.1.0.See also Software Versioning is Ridiculous).
But you can start by looking at the Eclipse Version Number policy as a good start.
If you really think you need more than three digits, this V.R.M.F. Maintenance Stream Delivery Vehicle terminology explanation is also interesting, but more so for post 1.0 software programs, where fix pack and interim fixes are in order.
"Ship it already":
1.0.0Also known as the "
1.oh-oh" version. At least, it is out there, and you can begin to get feedback and iterate fast.0.xif major features are still missing;1.0.0if the major features are there.Yes, but I would say only for large projects with a lifespan over several years (a decade usually)
Note that "correctly" (while being described at length in Semantic Versioning 2.0.0) can also be guided by more pragmatic factors:
See the announcement for Git 1.9 (January 2014):
Update Feb. 2019: semver itself is about to evolve (again, after semver2).
See "What’s next for SemVer", and
semver/semver/CONTRIBUTING.在我们公司，我们使用四个令牌版本控制概念。它类似于 abcd 类型：
它与我们在开发生命周期中使用的问题类型相关。我们可以一目了然地跟踪以下两个版本之间所做的事情或发生的变化。通过比较以下两个版本号，您可以确定已完成问题的数量和类型。
如需了解更多信息，完整文档位于此处。
At our company, we are using four token versioning concept. It's something like a.b.c.d kind:
It's related with issue types which we use in our development life cycle. We can track what has done or changed between two following versions at a glance. By comparing two following version numbers you can identify number and types of issues done.
For more information, full documentation is here.
即使我在使用 CRM 进行开发时也遇到了定义版本号的问题，因为我想在所有系统上部署相同的版本。我找到了用系统值+手动+随机来解决它的方法。
程序集的版本信息由四个值组成：
主要版本 。 次要版本。 内部版本号。 修订版
默认情况下初始版本为 1.0.0.0。为了更有意义，我将其替换为
TFS Release 。 TFS冲刺。 更改号码。 增量版本号
假设在您的 TFS 中，单个版本包含 30 个冲刺，之后版本变为 2，因此第一个版本的值将为：
TFS 版本：1
如果当前的 sprint 是 4，TFS Sprint 将有
TFS Sprint : 4
现在第三部分由开发人员管理，对于初始版本，我们可以有 0，每个 ChangeRequest 可以递增 +1 或错误修复。
更改编号：0 -- 代表初始版本
变更编号：1 -- 代表变更
Change Number: 2 -- 代表 bugfix
虽然每个 bugfix 都可能有代码更改，所以默认代表代码更改。但更有意义的是，您可以用奇数来表示更改，用偶数来表示错误修复。
最后一部分是默认版本号，幸运的是.Net 允许我们使用 * 来放置默认版本号。它随着每次编译/构建而不断增加，提供签名标记，如果其他人重建它会发生变化。
如何实现：
打开Properties文件夹中的AssemblyInfo.cs并注释AssemblyFileVersion，这将使AssemblyFileVersion &装配版本相同。
因此最终版本将显示为： 1.4.2.4512 或其他内容
这种方法的好处是您可以跟踪为其生成代码的任务。只需查看版本号，我就可以说：“嘿，这是 sprint 4 的版本 1，并且进行了一些代码更改。
Even i faced this problem with defining the version number while developing with CRM, since i wanted to deploy the same build across all the systems. I found a way to resolve it with System value + Manual + randoms.
The version information for an assembly consists of four values:
Major Version . Minor Version . Build Number . Revision
Which makes the initial Version 1.0.0.0 by default. To make more sense i replace it with
TFS Release . TFS Sprint . Change Number . Incremented build number
Suppose in your TFS a single release consists 30 sprints and after that the release becomes 2, so the values for the first release will be:
TFS Release : 1
If the current sprint is 4, the TFS Sprint will have
TFS Sprint : 4
Now the third part is managed by the developer, for a initial version we can have 0 which can be incremented +1 for each ChangeRequest or BugFix.
Change Number: 0 -- represent initial version
Change Number: 1 -- represent change
Change Number: 2 -- represent bugfix
Although for every bugfix there might be a change in code, so it represents the code change as default. But to more more sense you can have the odd number to represent the change and even number to represent the bugfix.
The last part was the default number, thankfully .Net allows us to put * to put a default build number. It keeps on increment with every compile/build which provides a signature stamp, if someone else rebuilds it changes.
How to Implement:
Open the AssemblyInfo.cs in the Properties folder and Comment the AssemblyFileVersion, this will make the AssemblyFileVersion & AssemblyVersion same.
So the final version will come out as: 1.4.2.4512 or something
The benefits of this approach is that you can track the Task for which the code is generated. Just by looking at the version number i can say, "Hey its the release 1 for sprint 4 and with some code change.
语义版本控制如今几乎已成为事实。
你没有缺少版本。这是完全可以接受的......（见下一个答案）
取决于人们是否在生产中使用您的代码。如果它已在生产中使用，请直接跳至
v1.0.0。但既然您说您的代码具有 alpha、beta 或 rc（候选版本）质量，但您计划快速投入生产，请考虑从v1.0.0-[alpha].N开始，其中[alpha]是软件等级，N是内部版本号或其他可枚举值。就是这个想法。字典排序可能不起作用，但没关系。
Semantic Versioning is pretty much de facto nowadays.
You're not missing versions. It's perfectly acceptable to… (see next answer)
Depends if people are using your code in production. If it's already used in production jump straight to
v1.0.0. But since you said your code is alpha, beta, or rc (release candidate) quality but you're planning to move to production quickly consider starting withv1.0.0-[alpha].Nwhere[alpha]is the software grade andNis a build number or other enumerable value.That's the idea. Lexicographical sorting may not work but that's okay.