【发布时间】:2014-08-01 16:42:30
【问题描述】:
我们有一个内部 Java 库,它是许多其他项目的依赖项,我们称之为 our-commons-<version>.jar。我们或多或少喜欢关注semantic versioning 的想法,所以:
- 当我们进行向后不兼容的 API 更改时,主要数字会发生变化;
- 当我们进行向后兼容 API 更改时,会发生少量更改;
- 每次我们进行构建时,补丁号都会更改(所以对我们来说,它实际上是一个构建号);但我们真的只会在修复错误时构建,所以它足够接近真实
semver
目前,我们只发布到 Artifactory 上的 SNAPSHOT 目录,并覆盖每次构建时存在的 JAR。具体来说,我们的项目仓库位于:
http://arty/artifactory/simple/our-libs-snapshots/our-commons/snapshot
http://arty/artifactory 是在 arty 机器上运行的 Artifactory 服务,our-libs-snapshots 是实际存储库的名称,our-commons 是我们的库的名称。 /snapshot 目录是所有 Bamboo 构建发布到的位置,就像我说的那样,覆盖每个构建的 JAR。我们正在对我们的构建进行硬编码,以便在每个构建中生成一个our-commons-0.1-SNAPSHOT.jar。
要进行此发布,我已将以下任务配置为 our-commons 的 Bamboo 计划的一部分:
Artifactory Deploy Task
=======================
Artifactory Serverl URL: http://arty/artifactory
Target Repository: our-libs-snapshots
Deployer Username: myadmin
Deployer Password: ******
Edit Published Artifacts: dist/our-commons-0.1-SNAPSHOT.jar=>our-commons/snapshot
Capture & Publish Build Info: yes (checked)
我正试图弄清楚如何让 Bamboo 和 Artifactory 与我们的 semver 风格一起工作。这样我们第一次构建时,它将产生:
http://arty/artifactory/simple/our-libs-snapshots/our-commons/1.0.0/our-commons-1.0.0.jar
而我们第二次构建时,它会产生:
http://arty/artifactory/simple/our-libs-snapshots/our-commons/1.0.1/our-commons-1.0.1.jar
等等。然后,我们可以手动指示何时增加次要编号,在这种情况下,补丁编号将重新开始:
http://arty/artifactory/simple/our-libs-snapshots/our-commons/1.1.0/our-commons-1.1.0.jar
主要编号的处理相同,但递增会重置次要编号和补丁编号。
不确定我们应该在哪里添加这些配置,或者它们的实际外观。有什么想法吗?
【问题讨论】:
-
只是为了好玩,你来自node.js/ruby背景吗? :)
-
感谢@JBaruch (+1) - 不,Java 背景。为什么?!?
-
滥用语义版本控制来实现快照行为对于来自这些 bgs 的开发人员来说是很自然的事情。
标签: java publish artifactory bamboo semantic-versioning