我正在C#
编写软件应用程序,目前我正在遵循(可能是最常见的)方案:
Major
。Minor
。Patch
。Revision
例如1.0.5.36182
。
为了定义应用程序是否处于测试阶段,我只需检查Patch
整数。它甚至是吗?发布。这是一个奇数吗?贝塔。
现在我从SVN切换到Git并希望在我的版本编号中使用提交。最优选:
Major
。Minor
。Patch
- commit hash
,例如1.0.5-47ad38f
。
答案 0 :(得分:1)
这个问题充满了意见,但我会尽力帮忙。
我建议只标记非测试版,并使用git describe
生成您的版本,例如: git describe HEAD
或git describe some-branch
。此命令的输出类似于
some-tag
,在这种情况下,您要求描述的内容(在此示例中为HEAD
或some-branch
)完全对应于代码some-tag
或 some-tag-<n>-g<hash>
,其中<n>
对应于some-tag
之后的提交次数,<hash>
对应于所描述的提交的哈希值。
例如,输出1.2.3-12-gabcd123
表示所描述的提交在标记1.2.3
之后是12次提交,并且散列为abcd123
。
在此方案下,输出像1.2.3
这样的简单标记的版本可以被认为是稳定的,而那些与1.2.4-12-gabcd1234
之类的标记相同数量的提交可以被视为不稳定。
如果您需要能够手动标记非稳定版本,那么您现在使用针对unstable的稳定和奇数补丁级别的补丁级别的技术应该可以正常工作,但您可能希望使用{{{{ 1}}和alpha
(或其他任意字符串)as recommended by semantic versioning。在这种情况下,严格定义了排序规则:
优先级是指在订购时如何将版本相互比较。必须通过按顺序将版本分为主要,次要,补丁和预发布标识符来计算优先级(构建元数据不会优先)。当从左到右比较每个标识符时,优先级由第一个差异确定,如下所示:主要版本,次要版本和补丁版本始终以数字方式进行比较。示例:1.0.0&lt; 2.0.0&lt; 2.1.0&lt; 2.1.1。当major,minor和patch相同时,预发行版本的优先级低于普通版本。示例:1.0.0-alpha&lt; 1.0.0。具有相同主要版本,次要版本和补丁版本的两个预发行版本的优先级必须通过从左到右比较每个点分隔标识符来确定,直到找到差异如下:仅由数字组成的标识符在数字上与标识符与字母进行比较或者连字符以ASCII排序顺序进行词汇比较。数字标识符的优先级始终低于非数字标识符。如果所有前述标识符相等,则更大的预发布字段集合具有比较小集合更高的优先级。示例:1.0.0-alpha&lt; 1.0.0-alpha.1&lt; 1.0.0-alpha.beta&lt; 1.0.0-beta&lt; 1.0.0-beta.2&lt; 1.0.0-beta.11&lt; 1.0.0-rc.1&lt; 1.0.0。
beta
的输出具有字母数字可排序的好处,只要您的标签以合理的方式命名即可。在语义版本控制的情况下,版本比较定义如上。
如果您手动标记不稳定的补丁级别并依赖奇数/偶数区分符,则比较会变得更加棘手。语义版本控制在这里可能是更好的选择,因为它具有明确定义的顺序。
&#34;检查新版本&#34;是一个棘手的主题;你想查询像GitHub这样的新标签并将它们与你当前的标签进行比较吗?