程序集版本化最佳做法问题，包括WRT Alpha，Beta等 [英] Assembly versioning best practice question wrt alpha, beta, etc

问题描述

我们希望在程序集中采用一些有关版本控制的最佳实践.由于我来自Java + Maven + OSGi背景，因此我将分享其进行版本控制的方式.

We'd like to employ some best practices with respect to versioning in our assemblies.  Since I'm coming from a Java+Maven+OSGi background, I'll share its way of doing versioning.

Java版本是任意的；没有平台规定的方案.但是，在相当长的一段时间内，版本具有典型形式

Versioning in Java is arbitrary; there are no platform-dictated schemes.  However, for quite some time now, versions have the typical form

major.minor.revision [.qualifier]

major.minor.revision[.qualifier]

主要& minor是不言而喻的，修订版用于表示非常小的更新，例如错误修复/热修复等，并且限定符用于发布者的方便.几乎总是，主要，次要&修订元素是数字 价值观，但不一定非要如此.订购如您所愿:主要版本是最重要的元素，并按字符串的顺序进行比较，除非将它们的所有数字都进行比较，在这种情况下，先对它们进行数字比较，然后进行次要比较，然后进行修订， 然后是限定词(如果有的话).因此，要给出新创建的库可能经历的版本控制方案的示例，请考虑以下带有说明的版本:

where major & minor are pretty self-explanatory, revision is used to indicate very minor updates like bug fixes/hot fixes, etc, and qualifier is used at the publisher's convenience.  Almost always, the major, minor & revision elements are numeric values, but they don't have to be.  Ordering is as you might expect:  major versions are the most signficant element and are compared by the string's order unless their all numeric, in which case they're compared numerically, then minor, then revision, then qualifier, if present.  So, to give an example of the versioning scheme that a newly created library might go through, consider the following versions with descriptions:

• 1.0.0.A1-alpha 1
• 1.0.0.A2-alpha 2
• 1.0.0.B1-beta 1
• 1.0.0.M1-里程碑1
• 1.0.0.M2-里程碑2
• 1.0.0.RC1-发布候选1
• 1.0.0.RC2-候选发布2
• 1.0.0.RELEASE-正式发布到制造业(又称正式")释放

注意，用于金色版本的版本字符串字面意思是"1.0.0.RELEASE"；也就是说，它具有".RELEASE".在1.0.0&的末尾.暗示是永远不会只有"1.0.0".版本字符串，因为将按顺序订购**之前 **任何预发行版本(alpha，beta，里程碑，候选发行版本等)的字符串.接下来，可能会修复一些错误，等等，但这并不重要；您只需增加版本元素，然后进行很少或太多的预发行版本 您想要的版本字符串.不再有服务包"等.

Notice that the version string for the version considered golden is literally "1.0.0.RELEASE"; that is, it has the ".RELEASE" on the end of the 1.0.0".  The implication is that there is never just a "1.0.0" version string, as that would be ordered **prior to** any prerelease (alpha, beta, milestone, release candidate, etc) version string.  Next, there might be bug fixes, etc, but it really doesn't matter; you just increment the version elements and go through as few or as many of the prerelease version strings that you want to.  No more "service packs", etc.

还要注意，如果要使用9个以上的Alpha，Beta等，则必须将限定符的格式设置为.A01，.A02，...，.A10，...，因为"; .A11"将在".A2"之前订购，这显然不是您想要的.实际上很少 但是，我见过9种以上的预发行类型的东西(Alpha，Beta等).

Also note that if you're going to have more than nine alphas, betas, etc., you would have to format the qualifier as .A01, .A02, ..., .A10, ..., because ".A11" would be ordered prior to ".A2", which is obviously not what you intend.  Rarely in practice, however, have I seen more than nine prerelease-type thingies (alphas, betas, etc).

让我们说一个1.0.0.RELEASE的错误修复是如此简单和明显，我们选择将其称为黄金"，而不必理会预发行周期，因此决定直接发行.它将具有以下版本:

Let's say that there is a bugfix to 1.0.0.RELEASE that is so simple and obvious that we choose to call it golden and don't bother with the prerelease cycles, deciding to go straight to release.  It would have the following version:

• 1.0.1.RELEASE-版本更新为1.0.0.RELEASE被认为是黄金

接下来，我们可能会通过1.0.1.RELEASE在市场上取得巨大成功，然后我们发现一个不确定的客户，我们不确定是否可以解决.在这种情况下，我们可以创建一个预发布的错误修正版本并进行分发:

Next, we may be experience great success in the market with 1.0.1.RELEASE, then we find a customer with a corner case that we're not sure we can fix.  In that case, we can create a prerelease bugfix version and distribute that:

• 1.0.2.RC1-将候选错误1发布到1.0.1.RELEASE

然后，我们发现这很好，因为我们的工程师很棒，我们希望将代码发布为黄金.现在，我们只需增加版本，而无需任何其他代码更改:

Then, we find out that it's good to go -- our engineers were great, and we want to release the code as golden.  Now, we just increment the version without any other code changes:

• 1.0.2.RELEASE-金色

您可以重复此模式.如果您喜欢整个内部版本号，或者想要在版本字符串中与使用者交流额外的信息，则可以使用所需的任何格式将其他内容放入限定符中，例如， "2.3.0.RELEASE.BN15332.201009141248-LOVELYBUNCHOFCOCONUTS".不管您用于限定词的是什么，它都是自然排序的，例如2.3.0.RELEASE优先于2.3.0.RELEASE.BN15332.201009141248-LOVELYBUNCHOFCOCONUTS，因为空的限定词 字符串要比非空的限定符字符串少.

You can repeat this pattern ad nausium.  If you like the whole build number thing, or want to communicate extra info to your consumers in the version string, you can put whatever other things into the qualifier using whatever format you want, for example, "2.3.0.RELEASE.BN15332.201009141248-LOVELYBUNCHOFCOCONUTS".  Whatever you use for your qualifier, it's ordered naturally, as a string such that 2.3.0.RELEASE precedes 2.3.0.RELEASE.BN15332.201009141248-LOVELYBUNCHOFCOCONUTS because the empty qualifier string compares less than a non-empty qualifier string.

使用此约定，我可以对Maven，Ivy，OSGi或任何了解此约定的人说，我的组件依赖于发布者的组件，其版本规范为"[1.0,2.0)"，表示1.0之前的任何版本包括1.0本身(正方形 括号表示版本小于2.0的任何内容(括弧表示独占").如您所料，保守的公司的版本执行政策可能是他们从不使用1.0s版本，而是选择 等待第一个错误修正版本发布，然后再使用其中的任何东西，包括主要更新: "[1.0.1，".或者，也许公司希望使用任何2.0或更高版本，但不希望升级到3.0，因为它们包含许多复杂的内容 害怕无法使用他们的东西: "[2,3)".你明白了.

With this convention, I can say to Maven, Ivy, OSGi or whatever understands this convention that my component depends on the publisher's component with a version specification of "[1.0,2.0)", meaning anything from 1.0 including 1.0 itself (the square bracket means "inclusive") through anything whose version is less than 2.0 (the parenthesis means "exclusive").  As you can imagine, then, a conservative company's version enforcement policy might be that they don't ever go with version 1.0s, preferring to wait for the first bugfix release and then use anything after that, including major updates:  "[1.0.1,".  Or maybe the company wants to go with any version 2.0 or later, but not jump to 3.0 because it's got lots of complicated stuff that they're afraid won't work with their stuff:  "[2,3)".  You get the idea.

现在，我的问题是:在.NET程序集中允许这种排序和版本内字符串通信的约定是什么?

Now, to my question:  what is the convention that allows this kind of ordering and intra-version-string communication in .NET assemblies?

根据文档，AssemblyVersionAttribute的约定为major.minor.buildNumber.revision，其中major& minor是相同的，但是buildNumber是自2000年2月1日以来的天数，修订版是该天的版本索引 (自那天午夜以来的秒数除以2-除以2对我来说似乎很奇怪).此外，版本元素中唯一允许使用的字符是数字.

According to the docs, the convention for AssemblyVersionAttribute is major.minor.buildNumber.revision, where major & minor are the same, but buildNumber is "the number of days since Feb 1, 2000 and the revision is the index of the build for that day (the number of seconds since midnight of that day divided by 2 -- the division by 2 seems odd to me).  Further, the only allowed characters in the version elements are digits.

其中没有用于alpha，beta等的空间.我在哪里指出某个给定的major.minor.revision是alpha，beta，里程碑，候选发行版，发行版还是alovelybunchofcoconuts?我如何合并这些 概念纳入版本控制方案，以便排序正确?我曾考虑过使用否定的版本元素值，但这也是不允许的.

There's no room for alpha, beta, etc. in that.  Where do I indicate that something is an alpha, a beta, a milestone, a release candidate, a release, or a lovelybunchofcoconuts for a given major.minor.revision?  How do I incorporate these concepts into the versioning scheme so that the ordering is correct?  I thought of using negative version element values, but that's disallowed, too.

有想法吗?

谢谢，
马修

Thanks,
Matthew

 

推荐答案

有些人避免了提出版本号方案并通过计算出下一个数字的全部复杂性只是用年，月和日填充这些地方.

Some people avoid the whole complexity of coming up with a version number scheme and figuring out the next number by just filling the places with the year, month, and day.

专业= 2010
次要= 9
内部版本= 14
修订版= 0  (如果同一天有多个版本，请在此处进行修改.其他选项是时段或标记.)

Major = 2010
Minor = 9
Build = 14
Revision = 0  (If multiple builds on same day, modify here.  Other options are time-of-day or flags.)

对于赞成使用日期的某些论点: http://www.codinghorror.com/blog/2007/02/whats-in-a-version-number-anyway.html

For some argument in favor of using the date: http://www.codinghorror.com/blog/2007/02/whats-in-a-version-number-anyway.html

 

这篇关于程序集版本化最佳做法问题，包括WRT Alpha，Beta等的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！