CLI should allow major and minor versions for bootVersion parameter

[mraible]

It'd be super fantastic if start.spring.io accepted the minor and major versions of Spring Boot instead of requiring it explicitly. That way, us poor saps writing tutorials about Spring Boot can have content that stays relevant longer. For example:

https start.spring.io/starter.zip bootVersion==3

Or even bootVersion=3.1. Please. 🙏

[snicoll]

I can understand why you'd want a bit of control over things. I am guessing you are aware you can remove the bootVersion from that link altogether and it'll offer the current GA. That is in my view much better than bootVersion=3.

If we implemented this, it would be the same way we do for metadata handling, e.g. 3.1.x or 3.x.x. But before we dig into this, please confirm that removing bootVersion doesn't work for you, and if so why? Thanks!

[mraible]

@snicoll Removing bootVersion works to get the latest GA. However, many of my tutorials have been QA'd with a certain version. Yes, y'all are great a backward compatibility, but sometimes things break or change between releases. If we remove bootVersion from our 3.x tutorials, we're just assuming that they'll work with 4.x, and that might not be the case.

[snicoll]

However, many of my tutorials have been QA'd with a certain version. Yes, y'all are great a backward compatibility, but sometimes things break or change between releases.

Right but if you ask for bootVersion=3, I don't really see the argument as it would also give you the latest GA for several years. I understand this may improve the situation a bit and I am open to implement it but that won't eliminate the problem of a major version going away. For instance, assuming bootVersion=2 implemented, this is going to break in a month or so when we remove support as 2.x will be out of OSS support.

From that perspective, removing bootVersion altogether isn't so bad IMO. The only difference is that you have a bit more time before it starts breaking due to it being out of support. I guess, as a tutorial author, you'd like to know sooner than that, don't you?

[mraible]

As a tutorial author, I'd love it if the bootVersion we specified worked forever. If we create an example on GitHub that has the completed tutorial, it will work forever because the artifacts stay on Maven Central forever.

However, I realize y'all like to remove versions after they're unsupported, so it makes sense that they go away on start.spring.io. Because of this, we try to create tutorials that clone a repo first rather than using start.spring.io first. In the cases where we create from scratch, we always specify the specific version because we know that works. If we could specify a major or minor version only, there is a risk of it not being QA'd, and there is a bug in newer releases, but we feel that risk is small.

If the major and its minor versions go away at the same time, maybe this doesn't matter from a deprecation standpoint. However, users will benefit because they'll get a newer version when doing the tutorial.

I know that npm allows major versions (e.g. npm i -g generator-jhipster@7), and it'd be nice if Java had something similar.

[snicoll]

If we create an example on GitHub that has the completed tutorial, it will work forever because the artifacts stay on Maven Central forever.

I am not sure this is a valid argument as neither you nor I want the community to learn something on a version that's out of support. At least, I suspect so!

If we could specify a major or minor version only, there is a risk of it not being QA'd, and there is a bug in newer releases, but we feel that risk is small.

Yes I got that. From that discussion, I acknowledge that having bootVersion=3.x.x would be useful during the time we swap from one major version to the next. However, this has the disadvantage that you won't get any feedback as the tutorial will continue to work on the previous generation as long as it is supported on the site. Once a major version is current and the tutorial works with it, I don't see an advantage compared to removing the bootVersion at all.

That said, the use case above is significant enough to consider adding support for it.