我的问题是,哪种版本命名方案应该用于什么类型的项目.
很常见的是major.minor.fix,但即使这样也可以导致4号(即Firefox 2.0.0.16).有些人有一个模型,奇数表示开发人员版本甚至数字稳定版本.所有类型的添加都可以进入混合,如-dev3,-rc1,SP2等.
存在理由偏好一种方案而不是另一种方案,并且不同类型的项目(即开源与封闭源)是否有不同的版本命名方案？
这有两个很好的答案(加上很多个人喜好,请参阅Gizmo对宗教战争的评论)
对于公共应用程序,标准Major.Minor.Revision.Build效果最好IMO -大众用户可以轻松地告诉他们有计划的什么版本,并在一定程度上能走多远过时的版本.
对于内部应用程序,用户从未要求提供应用程序,部署由IT处理,用户将调用帮助台,我发现Year.Month.Day.Build在很多情况下都能更好地工作.因此,可以对该版本号进行解码,以向服务台提供更有用的信息,然后提供公共版本号方案.
然而,在一天结束时,我会提出一个最重要的推荐 - 使用一个你可以保持一致的系统.如果有一个系统可以设置/编写您的编译器以便每次都自动使用,请使用它.
可能发生的最糟糕的事情是你发布的二进制文件的版本号与之前的版本号相同 - 我最近一直在处理自动网络错误报告(某些应用程序),并得出了Year.Month.Day的结论.构建在核心显示版本号转储,丝毫没有最新的应用程序本身(自身使用的闪屏与实数的应用程序 - 这当然不是在那里从二进制绘制为人们可能会认为).结果是我无法知道崩溃转储是来自2年前的二进制文件(版本号指示的是什么)还是2个月大的二进制文件,因此无法获得正确的源代码(也没有源代码控制! )
我是语义版本控制的狂热粉丝
正如许多其他人所评论的那样,这使用了XYZ格式并给出了原因.
这是我们在公司使用的:Major.轻微的.补丁版.内部编号.
的主要变化包括一个完整的发布周期,包括市场的参与等,这数字是由部队R&d之外controled(例如,在我工作的地方之一,市场决定,我们的下一个版本将是"11" -匹配一个竞争对手.我们当时的版本2 :)).
将新功能或主要行为更改添加到产品时,会更改次要.
每次将补丁正式添加到版本时,补丁版本会增加一个,通常只包括错误修复.
在为客户发布特殊版本时使用构建版本,通常具有特定于他的错误修复.通常该修补程序将汇总到下一个补丁或次要版本(而产品管理通常会将错误标记为"将在我们的跟踪系统中发布补丁3").
我们的研发部门使用1.0.0.0.0.000:MAJOR.minor.patch.audience.critical_situation.build
拜托,请不要这样做.
这种问题更多的是关于宗教战争而不是客观方面.对于编号方案或其他方案,总有很多优点和缺点.人们可以(或应该)给你的是他们使用的方案以及他们选择它的原因.
在我这边,我使用XYZ方案都是数字,其中:
X表示引入向后不兼容性的公共API的更改
Y表示添加了一些功能
Z表示修复(修复错误,更改内部结构而不影响功能)
最后,如果我想在正式发布之前得到用户的一些反馈,我会使用"Beta N"后缀.没有"RC"后缀,因为没有人是完美的,总会有错误;-)
我们更喜欢major.minor.milestone.revision- build计划,其中:
major:重大架构变更或功能重大进步的增量.
minor:不需要更改体系结构的小更改和新功能.
milestone:表示代码的稳定性和成熟度:
0表示开发/ pre-alpha
1表示alpha
2为测试版
3候选发布候选人(RC)
4用于最终/生产发布
revision:表示发行版,补丁程序或错误修正号.
build:对应用程序的特定构建或版本的唯一引用.构建号是一个连续的整数,通常在每次构建时递增.
1.4.2.0-798:版本的第一个beta版本1.4,由内部版本号创建798.
1.8.3.4-970:1.8-RC4,由内部版本号创建970.
1.9.4.0-986:版本的第一个生产版本1.9,由内部版本号创建986.
1.9.4.2-990:版本的第二个错误修正版本1.9,由内部版本号创建990.
由于生产版本始终具有4版本字符串的第3位数字,因此可以删除生产版本的数字.
我个人更喜欢MAJOR.MINOR.BUGFIX-SUFFIX,其中SUFFIX dev用于开发版本(版本控制检出),rc1/ rc2用于发布候选版本,并且没有发布版本的后缀.
如果您有开发结帐的后缀,甚至可能使用修订号,则无需使它们均匀/奇怪以使它们分开.
京公网安备 11010802040832号 | 京ICP备19059560号-6 