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

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

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

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

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

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

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

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

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

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

快照版本开发模式

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

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

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

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

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

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

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

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

@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 的问题。不过我没有计较，人家是好几年开发经验的正式工，而我只是实习生

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

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

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

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

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

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

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

所以其实 OP 心理其实早就想清楚了

@ldyisbest 那说到底还是你们的开发制度有很大的缺陷，没有人进行技术层面的管理。

这 还是开发流程有问题吧，snapshot 是作为开发版本或者测试版本发布的，既然两个系统对接那就不应该用这个版本号了。

不是有 maven 私服么, A 用他的 1.0-snapshot, B 用他的 1.1 不就好了

@DinnyXu #22 @yoloMiss #23 是的，开发制度有很大缺陷，没有人在技术层面管理。 并没有人在意用不用 snapshot
@bthulu #24 这样也可以，就是在新加功能的时候要打两个版本的包

你的包应该像其他 maven 依赖一样，两个包的版本并存再你们的 maven 私库里

@ldyisbest 为啥新加功能要打两个版本的包? 1.0-snapshot 打包放到仓库里就不用管了, 后面加新功能, 只打 1.1 的就好了. 谁需要新功能, 谁自己去升级到新版本. 不需要新功能的就不用强制升级.

@zzfer 是的，现在就是这样搞

@bthulu #27 就是 A 需要用新功能的，并且 A 不愿意升级版本。A 的版本是。1.0-snapshot

@ldyisbest 你没描述清楚，大家都以为是 A 不需要新功能，并且原来的 1.0 版本没有了。如果是 A 也需要新功能，你直接抽出身来，让 A 和 B 谈就行了，