Questions tagged «semantic-versioning»

1
语义版本控制如何应用于没有API的程序
在http://semver.org/(我认为这是版本控制中使用最广泛的约定)中,建议在引入破坏/修改API的更改时增加主版本号。 虽然有两种相关的情况,但我看不到如何应用此准则: 如果我的代码不提供任何API怎么办?我应该如何版本代码? 如果我的代码在开发的后期开始提供API,该怎么办?

2
为什么build.number是语义版本控制的“滥用”?
我解释提出了构建系统(摇篮/ Artifactory的/詹金斯/厨师),以我们的高级建筑师之一,他所提出的意见,我认为我的那种不同意,但我没有足够的经验,真正权衡上。 该项目构建了一个Java库(JAR)作为工件,供其他团队重用。对于版本控制,我想使用以下语义方法: <major>.<minor>.<patch> 其中patch指示错误/紧急修复,minor指示向后兼容的发行版,并major指示API的大规模重构和/或向后不兼容的更改。 就交付而言,这就是我想要的:开发人员提交一些代码;这将触发构建到QA / TEST环境。一些测试已经运行(一些自动化,一些手动)。如果所有测试均通过,则生产版本会将JAR发布到我们的内部仓库中。至此,应该正确地对JAR进行版本控制,我的想法是使用build.numberCI工具自动生成并提供的JAR 作为补丁号。 因此,版本控制实际上是: <major>.<minor>.<build.number> 同样,build.numberCI工具在哪里提供。 架构师对此表示否认,称使用CI版本号是语义版本控制的“滥用”。 我的问题是:这是正确的吗?如果正确,为什么?如果没有,为什么不呢?

4
何时不应该对提交进行版本标记?
上下文:我最近发现了语义版本控制,并且正在尝试确定如何在我自己的项目中最佳地实际使用它。 鉴于semver需要对主要更改,次要更改和补丁进行版本控制,何时不应使用更​​新的版本标记提交?在我看来,每项更改都将属于这些类别之一,因此,应对每项更改进行版本控制,但是当我查看GitHub上的各种流行项目时,这似乎并不是事情的完成方式(只是看一下实际上,大型项目只有数以百计的标签才有成千上万次提交。

5
什么时候应该增加版本号?
我不是在学校学习编程的,也不以(专业)开发人员的身份工作,因此很多基本知识对我来说还不太清楚。这个问题试图澄清其中之一。 现在,假设我有问题#1,#2并且#3在我的“问题跟踪器”中已设置要针对版本进行更正/增强,1.0.0并且最后一个(稳定)版本是0.9.0。 我1.0.0什么时候应该增加版本?当a)仅关闭了上面列出的问题之一,或b)当与版本相关的所有问题1.0都结束了? 哪一种是正确的方法?通过正确的方式,我指的是当前行业中使用的东西。

2
修复重要错误时的语义版本控制
我目前管理的图书馆有很多公共用途,并且我对语义版本化有疑问。我想重构该库的一个相当重要的部分,该部分执行不正确-始终执行不正确。但是,这样做将意味着更改公共API,这是一个重大决定。 我要进行的更改围绕如何使用迭代器展开。当前,用户必须执行以下操作: while ($element = $iterator->next()) { // ... } 至少在PHP的本机Iterator接口中,这是不正确的。我要替换为: while ($iterator->valid()) { $element = $iterator->current(); // ... $iterator->next(); } 类似于: foreach ($iterator as $element) { // ... } 如果您查看Tom的语义版本控制指南,他清楚地指出,对公共API的任何更改(即那些不向后兼容的更改)都应证明是主要版本的合理性。因此,该库将从1.7.3跳到2.0.0,对我来说,这是一个太远的步骤。我们只是在谈论一个已修复的功能。 我确实有计划最终发布2.0.0,但是我认为这是您完全重写该库并实现了许多公共API更改的时候。引入此重构是否需要发行主要版本?我真的不知道它是如何工作的-我更愿意将其发布为1.8.0或1.7.4。有人建议吗?

4
快速的主要版本是否表明设计不良?
几个月前,我开始担任初级程序员的工作。我们正在研究的系统已投入生产约2年。我没有参与系统和设计的乞讨。 我注意到的一件事是,系统主要版本已经是11.YZ。根据我在其他系统和库上的使用经验,我不记得看到如此快的产品碰撞主要版本的情况。有些产品已经在1.XY中使用多年,并且仍在接收功能和错误修正。 假设正确使用了语义版本控制,这是否表明系统设计不佳,因为它几乎每四个月进行一次重大更改?

2
语义版本控制是否允许版本号包含4个组件?
我所看到的所有语义版本控制示例都显示了3个使用中的组件。不超过2个句点字符。在$DAYJOB,我们在发行版号中使用4个组件: 5.0.1.2 语义版本允许吗? 作为一个更高层次且更具争议性的附带问题,这真的很重要吗?我开始认为实施语义版本控制可能是一个好主意,但最终像PCI这样的实体会覆盖它。 我应该在我的PCI评论中弄清楚。问题在于,当主要和次要组件发生更改时,审核及其成本会受到影响,而这不一定是真正的新功能。例如,如果引入了与付款相关的功能,我们将为PCI分配次要数字。但是,如果我们在gui中添加了与某物相关的全新功能,则不会。仅补丁程序更改。因此,在这种情况下,作为开发人员,我们实际上没有发言权,因为其他人会做出这些决定。

5
如何对待用户认为是功能的错误?
问题: 解决最终用户认为是功能的错误的正确方法是什么? 详细说明: 我猜想,如果很大一部分用户希望将其作为一项功能,应该将其“未固定”还是“固定”才能更稳定?但是,如果很少的用户期望它是一项功能,例如0.1%或1%,该错误必须得到解决。 从理论上讲,由于这是一个较小的错误修复程序,因此按语义版本控制考虑,它可以称为PATCH:xyZ但是,由于它确实破坏了向后兼容性(即使仅针对少数用户),因此应该是主要的提高:Xyz正确吗?只要有文件记载,它是否仍可以称为PATCH(因为它原本不是功能)? 编辑:在这种特定情况下,这是其他开发人员使用的内部使用库的API中的错误。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.