3

我知道快照是正在开发中1.0-SNAPSHOT的东西，即最终将作为1.0.

但我为什么需要它？

这是流程：

  • Major.Minor.Revision[.Build]我使用语义版本控制模型开发库。
  • 我明确定义了Majorand Minorwhile Revision(or Build) 由 CI/CD 管道自动递增
  • 接受 PR 并成功运行门控构建后，新版本将发布到公司的私有存储库。
  • 在依赖项目中，我指定了精确版本或浮动版本Major.+。

这里有地方SNAPSHOT吗？

4

1 回答 1

3

这是一个巨大的话题。让我评论一些与我们公司相关的观点。

  • 我们构建包含具有大型依赖树的 jar 的 ear 文件。在开发中，您经常需要在树的深处进行修复。如果您使用 SNAPSHOT 版本，每个人都会在下一次构建中自动绘制这些更改。如果你使用内部版本号，结果必须从下到上传播，即如果你有一个依赖层次 A -> B -> C 并且你构建了一个新版本的 C，你需要一个新版本的 B 然后A 的新版本。或者，您可以在最高级别（在我们的例子中为耳朵级别）使用 dependencyManagement 管理版本，以避免在 jar C 中的错误修复更改后重建所有内容。

  • 我们的开发人员需要构建“半个功能”，以便在开发过程中向我们的客户展示它们。这些通常构建为 SNAPSHOT 版本，而不是放入部署管道中。SNAPSHOT 版本允许您在语义上将这些版本与那些旨在生产的版本区分开来。

  • SNAPSHOT 和发布版本之间的区别可以用作快速猜测工件质量的方法（如果所有工件都有编号 xyz，哪些是好的哪些是坏的？）

  • 构建可重复性是一个重要目标，但从与我们的开发人员的讨论中，我知道对此有不同的看法。一些开发人员看重版本更新是否“自动”发生——他们说“最新版本总是正确的版本，我为什么要进行所有这些手动更新？”

于 2017-10-12T08:55:09.750 回答