如何做版本号？

我的公司正在建立一个产品.它将由SVN版本化.它是一个webapp,所以基本上永远不会有一个版本没有其中的某些功能,因此可以始终标记为beta.但由于它将成为一种企业产品,我真的不希望那里出现"不稳定的监视".那么你将如何进行版本控制呢？1.0稳定吗？构建日期应该是版本号吗？告诉我你们在想什么!

1> Assaf Lavie..：

---

[ 专业 ].[ 未成年人 ].[ 发布 ].[ build ]

专业:真的是一个营销决策.你准备好打电话给1.0版吗？公司是否认为这是客户可能需要支付更多费用的主要版本,还是可能免费的当前主要版本的更新？较少的研发决策和更多的产品决策.

minor:每当major增加时从0开始.每个公开的版本都有+1.

发布:每当您达到开发里程碑并发布产品时,即使在内部(例如QA),也要增加它.这对于组织中的团队之间的沟通尤为重要.不用说,永远不要发布两次相同的'发布'(甚至内部).在次要++或主要++上重置为0.

build:可以是SVN版本,我觉得效果最好.

---

这几乎与我对软件版本控制的定义相符.但是,一旦我增加"次要"版本号,我就将版本重置为0.

---

@Brain:看看`git describe`

---

这个答案太老了......我简直不敢相信我曾经使用过SVN.:OI想知道Git的最佳实践是什么.也许是提交哈希的前几位数？在做"git show [build]"时,有一个很好的机会获得一个独特的匹配？

---

如果使用git,对于未成年人有什么用？

---

布莱恩:你的意思是建造吗？

2> Itay Moav -M..：

---

xyzg

g的增量是不稳定的.z中的(或RC)增量是稳定的并且意味着错误修复.
y中的增量是稳定的并且意味着新的特征.
x中的增量是稳定的,主要版本没有100%向后兼容性.

---

关于G点我不确定,其余的很常见.

---

@ ItayMoav-Malimovka承认它,你使用'g'只是为了让你可以开玩笑.

---

这是你的方式还是常用的？

3> DevSolar..：

---

我曾经为我的一个大型项目写了一篇精心设计的"版本风格指南".该项目未能实现,但风格指南仍可在线获取.这是我个人的看法,也许对你有帮助(或鼓舞人心).

要注意,这是一个很长的文本,并进入组件版本控制与产品版本控制和类似的东西.它也对OSS社区中流行的一些版本控制方案表达了强烈的意见,但我有它们,所以我表达了它们.;-)

例如,我不同意使用Subversion版本号.您可能希望在继续TRUNK开发的同时维护已发布的版本,因此您将设置维护分支 - 并且您的版本号版本将耗尽.

编辑:作为摘要,它区分版本控制源文件,组件和整个产品.它使用一个单独的xy系统的组件和产品系统,两者之间有很好的相互依赖性,这使得跟踪哪个组件版本属于哪个产品版本是微不足道的.它还讨论了如何在不破坏系统的情况下处理alpha/beta/release/patch周期.实际上,它是整个开发周期的运作方式,所以你可能想要挑选.;-)

编辑2:由于有足够的人发现我的文章有用,使其成为"不错的答案",我再次开始研究这篇文章.现在可以使用PDF和LaTeX版本,只要能找到时间,我们就会立即进行完整的重写,包括更好的语言和解释性图形.谢谢你的投票!

4> scable..：

---

从维基百科中获取灵感:"软件版本控制"

另一个"新"和"相对流行"的选项是语义版本控制

摘要:

给定版本号MAJOR.MINOR.PATCH,增加:

进行不兼容的API更改时的MAJOR版本,

当您以向后兼容的方式添加功能时的MINOR版本,以及

PATCH版本,当您进行向后兼容的错误修复时.

预发布和构建元数据的附加标签可用作MAJOR.MINOR.PATCH格式的扩展.

---

@iconiK - 如果你使用SO,你肯定明白"这是一个清晰,简洁的答案在同一页面上与其他答案"比"这是一个链接到一个不同的网站,你可以挖掘旧版本的文章和也许找到相关的东西."

---

@Ravi - 也许,但它可能被破坏.因此需要声誉来编辑.对于略读这个问题的人来说,总结至少会更好.

5> Alexis Gamar..：

---

A B C D

增量:何时
- d:错误修复
- c:维护,例如性能改进
- b:新功能
- a:架构更改

强制性是最左边的,例如,如果有新功能和错误修复,那么你只需要增加b.

6> KarlKFI..：

---

根据我在复杂的企业平台级别依赖管理和发布版本控制方面的经验,我开始推荐一种我称之为半语义版本控制的方法.

基本上它是基于语义版本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中编写了一个半语义解析器.我不仅需要使用此模式,还能够管理使用它的其他应用程序.