我的公司正在建立一个产品.它将由SVN版本化.它是一个webapp,所以基本上永远不会有一个版本没有其中的某些功能,因此可以始终标记为beta.但由于它将成为一种企业产品,我真的不希望那里出现"不稳定的监视".那么你将如何进行版本控制呢？1.0稳定吗？构建日期应该是版本号吗？告诉我你们在想什么!
[ 专业 ].[ 未成年人 ].[ 发布 ].[ build ]
专业:真的是一个营销决策.你准备好打电话给1.0版吗？公司是否认为这是客户可能需要支付更多费用的主要版本,还是可能免费的当前主要版本的更新？较少的研发决策和更多的产品决策.
minor:每当major增加时从0开始.每个公开的版本都有+1.
发布:每当您达到开发里程碑并发布产品时,即使在内部(例如QA),也要增加它.这对于组织中的团队之间的沟通尤为重要.不用说,永远不要发布两次相同的'发布'(甚至内部).在次要++或主要++上重置为0.
build:可以是SVN版本,我觉得效果最好.
xyzg
g的增量是不稳定的.z中的(或RC)增量是稳定的并且意味着错误修复.
y中的增量是稳定的并且意味着新的特征.
x中的增量是稳定的,主要版本没有100%向后兼容性.
我曾经为我的一个大型项目写了一篇精心设计的"版本风格指南".该项目未能实现,但风格指南仍可在线获取.这是我个人的看法,也许对你有帮助(或鼓舞人心).
要注意,这是一个很长的文本,并进入组件版本控制与产品版本控制和类似的东西.它也对OSS社区中流行的一些版本控制方案表达了强烈的意见,但我有它们,所以我表达了它们.;-)
例如,我不同意使用Subversion版本号.您可能希望在继续TRUNK开发的同时维护已发布的版本,因此您将设置维护分支 - 并且您的版本号版本将耗尽.
编辑:作为摘要,它区分版本控制源文件,组件和整个产品.它使用一个单独的xy系统的组件和产品系统,两者之间有很好的相互依赖性,这使得跟踪哪个组件版本属于哪个产品版本是微不足道的.它还讨论了如何在不破坏系统的情况下处理alpha/beta/release/patch周期.实际上,它是整个开发周期的运作方式,所以你可能想要挑选.;-)
编辑2:由于有足够的人发现我的文章有用,使其成为"不错的答案",我再次开始研究这篇文章.现在可以使用PDF和LaTeX版本,只要能找到时间,我们就会立即进行完整的重写,包括更好的语言和解释性图形.谢谢你的投票!
从维基百科中获取灵感:"软件版本控制"
另一个"新"和"相对流行"的选项是语义版本控制
摘要:
给定版本号MAJOR.MINOR.PATCH,增加:
进行不兼容的API更改时的MAJOR版本,
当您以向后兼容的方式添加功能时的MINOR版本,以及
PATCH版本,当您进行向后兼容的错误修复时.
预发布和构建元数据的附加标签可用作MAJOR.MINOR.PATCH格式的扩展.
A B C D
增量:何时
- d:错误修复
- c:维护,例如性能改进
- b:新功能
- a:架构更改
强制性是最左边的,例如,如果有新功能和错误修复,那么你只需要增加b.
根据我在复杂的企业平台级别依赖管理和发布版本控制方面的经验,我开始推荐一种我称之为半语义版本控制的方法.
基本上它是基于语义版本2.0,但不是那么严格.
半语义版本段:
[- ][+ ]
主要版本段格式:
MARKETTING.MAJOR.MINOR.PATCH
每个段应允许字母数字,但建议使用纯数字进行逻辑增量更改.
与SemVer一样,我建议使用Major,Minor和Patch组件来表示反向兼容性层,但我还建议预先添加Marketing组件.这使得产品所有者,功能史诗/群组和业务问题可以独立于技术兼容性问题而突破主要组件.
与其他答案不同,我不建议在主段上附加内部版本号.相反,在'+'之后添加一个Post-Release Segment(例如:1.1.0.0 + build.42).SemVer调用此构建元数据,但我认为Post-Release Segment更清晰.此段非常适用于将后缀数据声明为与主发布段中的兼容性信息无关.然后,您的持续集成构建可以获得先前的版本号,该编号附加了在每个主要版本之后重置的增量版本号(例如:1.1.0.0 - > 1.1.0.0 + build.1 - > 1.1.0.0 + build.2 - > 1.1.0.1).有些人喜欢将svn修订号放在这里或者使用git commit sha来使它易于绑定到代码库.另一种选择是将后发布段用于修补程序和修补程序,因此可能值得考虑为此添加新的主要版本组件.当补丁组件递增时,它总是会被丢弃,因为版本实际上是左对齐和排序的.
除了发布和发布后的细分,人们通常还希望使用预发布细分来指示几乎稳定的预发布,如alphas,beta和候选发布.SemVer的方法效果很好,但我建议将数字组件与字母数字分类器分开(例如:1.2.0.0 + alpha.2或1.2.0.0 + RC.2).通常情况下,您会在添加后发布段的同时碰撞发布段,然后在下次碰撞主发布段时删除预发布段(例如:1.0.1.2 - > 1.2.0.0-RC.1 - > 1.2.0.0).添加预发布段以指示发布版本即将发布,通常只是一组固定的功能,用于更深入的测试和共享,基于更多提交不会每分钟更改.
以几乎涵盖所有用例的方式对所有这些语义定义的美妙之处在于,您可以以标准方式对它们进行解析,排序,比较和递增.当将CI系统用于具有许多小型独立版本组件(如微服务)的复杂应用程序时,这一点尤其重要,每个组件都有自己的托管依赖项.
如果您有兴趣,我在ruby中编写了一个半语义解析器.我不仅需要使用此模式,还能够管理使用它的其他应用程序.
京公网安备 11010802040832号 | 京ICP备19059560号-6 