Repository navigation
CLI should allow major and minor versions for bootVersion parameter #1479
Description
Activity
I can understand why you'd want a bit of control over things. I am guessing you are aware you can remove the
bootVersionfrom that link altogether and it'll offer the current GA. That is in my view much better thanbootVersion=3.If we implemented this, it would be the same way we do for metadata handling, e.g.
3.1.xor3.x.x. But before we dig into this, please confirm that removingbootVersiondoesn't work for you, and if so why? Thanks!@snicoll Removing
bootVersionworks 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 removebootVersionfrom our 3.x tutorials, we're just assuming that they'll work with 4.x, and that might not be the case.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, assumingbootVersion=2implemented, 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
bootVersionaltogether 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?As a tutorial author, I'd love it if the
bootVersionwe 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.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.xwould 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 thebootVersionat all.That said, the use case above is significant enough to consider adding support for it.
- changed the title
[-]start.spring.io should allow major and minor versions for `bootVersion` parameter[/-][+]CLI should allow major and minor versions for `bootVersion` parameter[/+]on Oct 23, 2023 - changed the title
[-]CLI should allow major and minor versions for `bootVersion` parameter[/-][+]CLI should allow major and minor versions for bootVersion parameter[/+]on Aug 14, 2026 Closing in favor of #1797.
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:
Or even
bootVersion=3.1. Please. 🙏