Document naming best practices for 1.x and 2.x support

[snicoll]

Third party support is now moving to Spring Boot 2 which sometimes require a dedicated starter. It would be worthwhile to expand our existing Wiki page to explicitly reference that.

In particular, I've seen a few cases of acme-spring-boot-1-starter and acme-spring-boot-2-starter that we should clearly describe as bad practice.

[wilkinsona]

I'm not sure that is bad practice, at least not all of the time. An example came up on Gitter the other day where the starter's version matched its project's version. That meant that having a new major version of the starter for Spring Boot 2 wasn't really an option. Including the Boot version in the starter's artifact id seemed like the best alternative.

[snicoll]

Thanks for the feedback. I saw that use case and I agree that we need to provide a solution. I do believe that including the version of Spring Boot is a bad practice.

Considering an artifact that provides support for both.

Right now, the Spring Boot 1 version is mainstream while the Spring Boot 2 one is opt-in (as you may not want to jump on Spring Boot 2 just yet). So v1 is the "default" and v2 is something you'd like to select.

In X months (or when that library will release a new major release), the reverse will happen: Spring Boot 2 will be mainstream and Spring Boot 1 is "maintenance" and opt-in. IMO, it would be nice if the library had a way to "enforce" that migration path.

In X years, Spring Boot 3 is out.

IMO, adding the version in the identify of the artifact is a bad idea for that reason. The default name can switch from Spring Boot 1 to Spring Boot 2 when that new major release is out. The "experimental" starter can go away (until Spring Boot 3 is out) and a "maintenance" starter could be created for Spring Boot 1. Those names are wrong obviously (otherwise I'd have written a more format proposal in my initial description).

Does any of this make sense?

[ruifigueira]

I was able to keep a single starter that aggregates two autoconfigure modules, one for each Spring Boot version, and use @ConditionalOnClass with Spring Boot classes that are specific to a version to select which of those autoconfigure modules would actually load. More details can be found at togglz/togglz#271 (comment).

This approach works fine for my use case, and doesn't require that I change my starter dependency based on the Spring Boot version. Of course, I may be missing something here, and I don't know if it's actually a pattern that you fell comfortable with.

I would like to use as much as possible the best practices in that contribution, so I'm very interested in the outcome of this ticket.

[snicoll]

@ruifigueira thanks a lot for the feedback. as far as naming is concerned, moving this from the starter to the autoconfigure doesn't change anything and I still think having a spring boot generation "number" in the artifact id is wrong.

We'll try clear this out and provide clear guidelines ASAP.

[ruifigueira]

I don't like having the version in the autoconfigure module names neither, so I'll hold togglz/togglz#271 until
there is a naming best practice for these cases.

I also went ahead and opened #12941, I don't want to hijack this thread on how to load different AutoConfiguration classes / modules based on Spring Boot version.

[snicoll]

FTR there is a good discussion on the togglz issue that could be used as a base for the recommendations here.