1

I am creating a shared library that will be used in many projects in my company. Those projects are based on different Spring-Boot versions. The same version of library won't work (as far as I know) for example on Spring Boot 3.0.0 and 2.7.10 projects. I don't know what are best practises to do versioning in such case. I believe I shouldn't make library version 1.0.0 for SB 2.7 and library version 2.0.0 for SB 3.0.0, because in some time I might need to increment the major version in the library due to breaking changes and I won't be able to increment 1.X.Y to 2.0.0.

What is the solution to this problem? Should I append something to the artifact name for each version?

Marcin K.
  • 683
  • 1
  • 9
  • 20

1 Answers1

1

There is not really a standard way. You could:

  1. Use version numbers like 2-1.0.0 and 3-1.0.0 to indicate the Spring Boot version.
  2. You could add the version to the artifactId like my-cool-library-sb2, my-cool-library-sb3.
  3. You could create both artifacts using the same GAV, but with different classifiers, like springboot2 and springboot3.

The first approach has the disadvantage that people might accidentally switch from Spring Boot 2 to Spring Boot 3 when updating the versions in their POM.

The second approach has the disadvantage that you might accidentally load both libraries (through transitive dependencies) because they do not share the same coordinates any more.

The third approach has the disadvantage that you only have one POM for both artifacts which means all dependencies have to be in the same version.

J Fabian Meier
  • 33,516
  • 10
  • 64
  • 142
  • I'm starting to lean towards the first approach, since the disadvantage that you mentioned might actually be an advantage in my case. We have a parent pom for the projects where we have dependencyManagement section where we specify the version of your dependencies. This parent is tied to a specific version of spring boot. Long story short when switching from spring boot X to springboot Y the project should just change the version of our parent and the parent should provide the library version via dependencyManagement section. – Marcin K. Jul 31 '23 at 12:06
  • I believe it would be more clean to use classifier, but classifier is - as far as I have checked - more an extension of artifactId, that extension of the version. That means you can't put a classifier only in dependencyManagement - you also need to specify classifier in actual dependency. This would violate the assumption that I have made that clients/end projects shouldn't need to modify anything other than the main parent version. The parent pom in my solution is pretty much an extended version of spring-boot-dependencies that include the versions of our core libraries. – Marcin K. Jul 31 '23 at 12:09
  • Hey! I just wanted to say that classifiers approach - which I have used eventually - was a dead end. It was due to the fact that classifier is just for jars and not for poms. Those versions need different pom versions and I'm having huge dependency problems now. Dependency hell. I think I will just go with what industry usually does - changing the name of the artifact for different version. – Marcin K. Aug 29 '23 at 10:59
  • @MarcinK. Sorry, but I mentioned that in my answer already. – J Fabian Meier Aug 29 '23 at 13:21
  • 1
    Oh that's true. I skipped that probably because I first (after reading your answer) decided to go with versions approach and then only changed to classifiers after talking with my coworker and I haven't checked with your answer again. If I read your answer again that would have saved me a lot of time. Thanks. – Marcin K. Aug 29 '23 at 13:38