jar 包版本管理有感，想了解下大家是怎么样做的，以及这些遇到这些情况怎么处理

[ldyisbest]

事情是这样的对接项目，刚开始对接的 A ，版本号是 1.0-snapshot ，然后对接 B ，版本号升级 1.1 ，后来又有新业务对接 A 的时候，A 说“这干嘛加版本号”，“每次你改我还得在改一下我的 pom 文件”，“上一次 XX 就是这样搞的 我的生产线上代码直接报错了”，“这东西最好不要改 要不然 每次都得沟通一下”，于是我作为一个实习生，就没有争辩，就把版本号改回去了，改成了 1.0-snapshot （之前他引用的版本），然后新业务对接 B ，给 B 说版本号是 1.0-snapshot ，B 说之前都升到 1.1 了怎么又改回去了，然后叨叨了一大堆。A, B 是一组的，B 是那个组的组长，还说什么版本号达成共识就行，自己一个组的人都没达成共识。

问题：

1. maven 版本号，大家公司的实践是怎么样的
2. A 是啥意思，是纯粹的懒还是不升版本号确实不会出错，我的理解是不生版本号更容易出错且会更混乱，上家公司实习的时候大家都升版本号，也都没什么异议。
3. 由于 A 不让升版本号，导致版本号回退，后来对接 B 的时候，导致 B 觉得是我们在瞎搞。 想请问大家面对 A 这样的开发的时候要怎么处理，我是实习生的身份，我当时的做法是妥协 A 。

我为啥一直是实习生，本科大四的时候在一家几百人的公司实习，后来觉得没劲就考研了，再后来就在这家公司实习，这家公司是国企，开发大概 50 人左右

[gexyuzz]

参考： https://caosg.gitbooks.io/java-devepment-rules/content/project/maven.html

[mineralsalt]

首先, 每次发版本, 版本号必须累加, 这是铁律. A 的问题让他自己去解决

[dayeye2006199]

这个公司没有 artifacts repository 的吗？
多版本号共存应该也不影响使用才对，各个项目依赖不同版本是可以的。

[cppc]

A 的想法也正常，你维护的 lib 升级了新版，应该有一种机制让使用方知道改动了什么，升还是降自己看着办。从你的描述看应该是 B 有新需求导致升级，那这跟应该没关系才对，所以没理由让别人跟着升级

[passer9527]

我们所有服务都是 1.0-snapshot ，全部统一。就为了避免楼主这种问题

[buliugu]

开发用 SNAPSHOT,生产用 RELEASE ，RELEASE 必须升版本

[Lighfer]

我们的解决方案是使用远程依赖加载，开发环境下，非 API 层面的变动，依赖的提供方直接替换远程的版本即可，正式发布前则要求引用方必须更新版本号。

[Buges]

要看具体引用的方式。如果是引用某个固定的版本，发新版本自然按正常流程升级。如果是引用 git/devel/master 滚动版本，那才是每次都拉取最新 /主线版本。

[alexmy]

A 用 1.0 ，B 用 1.1 。应该都有 maven 私库，都是共存的吧。

[ikas]

快照版本开发模式

开发过程中使用 snapshot 版本,但是正式版本禁止使用 snapshot 版本

比如你们需要开发 1.0 版本,那么开发过程选择 快照版本开发模式,那么版本就是选择 1.0-snapshot ,然后一直开发提交,中间也可以将 1.0-snapshot 推到自己的 maven 中央库,别人的项目也会拉取你这个最新的版本

当你开发完成后,那么这时候就是将此时的 1.0-snapshot ,定为 1.1 或者 2.0 等等...

当开始下一个版本时,就是 1.1-snapshot,2.0-snapshot,等等

[Niphor]

我觉得这是人际关系的问题，和升不升一点关系都没有

[DinnyXu]

我们现在一个项目有几十个微服务，关于版本相互依赖这件事，最好是有个私服仓库进行管理，一楼的是最标准的答案，也是我们目前实施的方案。

A 的想法就是个错误的想法，你既然微服务 A 产生了代码变动，如果是小迭代升版本是应该的，而不是为了“偷懒”或者说改了要沟通什么的... 你升级版本，别人需要依赖你的微服务，自然就要把版本写成跟你一样的，我认为这是理所应当的，还有就是你 A 升级为 1.1 后，正常来说会有个 relase 版本在私服管理着的，这样 B 就不需要改动。

最根本的原因还是你们没有私服管理....还有就是 A 太懒了....

[ldyisbest]

@dayeye2006199 #3 artifacts repository 是什么，我们有 maven 的私服，微服务的 api 会打包部署到私服

@cppc #4 都是微服务，我们的微服务有 api 和 service ，api 是打成 jar 提供给别人引用的，因为要新增加接口，于是就升级 api 的 jar 包的版本，但是 A 不愿意升级 jar 版本

@passer9527 #5 我觉得不改 jar 版本是很混乱的，毕竟 maven 仓库设计的时候就带有版本号，比如要删除某些 API ， 有些人还没迁移，那么那些人打包的时候就会报错

@buliugu #6 我们没有区分，都是一个 maven 仓库，snapshot 和 release 也是混用

@Lighfer #7 我修改的就是微服务的 API 层，新业务新增加了个接口，打 jar 包升级了版本号，所以我认为他应该引用新的版本号

@Buges #8 是微服务的接口层，

@alexmy #9 是的，新增加功能 A 也不愿意升版本，这样的话 每次增加需求 除了正常升级版本打一个包，还要打一个 1.0 的包（给 A 用，暂时是这样）

@ikas #10 是的，但是 A 不愿意改他的 pom ，我觉得他认为这样需要沟通成本，并且可能会出错，代价比较高。

@Niphor #11 是滴，说的太对了，我想问的就是这样该怎么处理， 我的情况是我是实习生（差不多可以算 2 年开发经验吧） 国企 几十人开发，所以我就无所谓他们怎么搞，他们说啥就是啥

@DinnyXu #12 有私服仓库，但是没有规范约束如果使用，个人也觉得是 A 的问题。不过我没有计较，人家是好几年开发经验的正式工，而我只是实习生

[Lighfer]

@ldyisbest 如果是生产环境中已经在使用的 API ，不建议直接发生变化，有 BUG 内部处理，新功能必须改接口就新增一个，或者按版本号划分。生产环境中其他服务正在稳定使用的任何接口非必要不要动。
即使是在开发环境，频繁发生 API 变更也会大幅降低团队的工作效率的。

[Lighfer]

这个问题无论用 snapshot 版还是远程加载或者其他的，你 API 一旦变了，别人的代码中如果有用到，就不得不跟着改，这对引用方来说就不是只改个版本号这么简单了

[ldyisbest]

@Lighfer #14 是的，我同意你的看法，我的做法就是新增了一个接口，并且本身就是新业务 新增接口，并且增加了 api 层的 jar 的版本号。在这个情况下 A 也不愿意改他的 pom 文件

[ldyisbest]

@Lighfer #15 我没有改任何已有的接口，使 A 需要改动他的代码

[Niphor]

这种还是得看里面每个人的人际关系有没有摸清了，谁强硬、谁说话好使。然后动态都发部门群里...先当缩头乌龟。
转正了你管他是谁，只要领导觉得你行就行了

[ldyisbest]

@Niphor #18 国企要钱没钱，要技术没技术。不打算转正，6 月份准备跑路了，不找事还好说，现在谁刚我我刚谁。研究生全职实习月薪 3.5k ，干的活跟正式员工一样，前段时间还算绩效，连 3.5k 都发不到玩个毛

[ldyisbest]

@Niphor #18 在多说一个事，A 之前私自改线上数据库（ A 有线上权限，数据库的权限管理也很乱），几百万的表，增加一个字段，把线上应用卡崩溃了十来分钟。没过多久又私自改库，把线上应用卡崩溃了十来分钟。 实在是没眼看