Quarkus LTS versioning

[kny78]

Description

I believe that the version schema for Quarkus should indicate if it is an LTS.

Either a new Major version is made for the LTS series, or the LTS versions should be the subsequent minor versions in the current major version. Then the new development (snapshot?) version should be tagged with a new major number.

For example 3.8 and 3.8+ should be:

LTS:

• 3.8.0 → 3.8.0
• 3.8.1 → 3.8.1
• 3.8.2 → 3.9.0

Development version:

• 3.9.0 → 4.0.0
• 3.10.0 → 4.1.0
• 3.11.0 → 4.2.0
• 3.11.1 → 4.2.1

PS: I don't mean we should change existing versions, but we should apply this for the future versions.

I expect that development versions have a different major version number than the LTS version.

Implementation ideas

No response

[gsmet]

Thanks for the suggestion but I'm not sure it's a good idea.

Changing a major version has a meaning: it usually says that there are very major changes to the library that will make the update complex.

If we take the case of 3.8/3.9, 3.9 is the direct continuation of 3.8.

LTS is about having long term support for a specific version. It doesn't mean the end of a given major. For instance, both 3.2 and 3.8 are LTS versions.

Could you explain why you would expect a new major? I don't see what it would bring to the plate?

[yrodiere]

3.8.2 → 3.9.0

... Why?

Changing a major version has a meaning: it usually says that there are very major changes to the library that will make the update complex.

+1, semantic versioning is what the current versioning scheme is about: https://semver.org/
Though I'll admit we're not always following it very strictly -- sometimes reality requires compromises.

[geoand]

Thanks for dropping your thoughts on this!

It's nice to see suggestions like this, but I believe that if we elected to move to such a model, it would not dispel confusion, but instead create more of it.

[geoand]

I'm actually going to convert this to a discussion as I think it fights that category better

[kny78]

I think the Quarkus project should follow the ideas behind https://semver.org/:

• MAJOR version when you make incompatible API changes
• MINOR version when you add functionality in a backward compatible manner
• PATCH version when you make backward compatible bug fixes

How we found out about LTS:

We didn't know that 3.2 and 3.8 was considered LTS versions, and we happily upgraded to other minor version as well.
There is nothing that shows us that 3.8 is stable, while 3.9 is a development version, until we see that we have to upgrade to Quarkus-Rest and functionality stops working.

Breaking change 1: Quarkus-Rest

This means that if I increase the minor version 3.8 → 3.9, or even 3.8 → 3.11, there should be no code changes on my side.
With the RestEasy → Quarkus-Rest change this is obviously not the case.

Breaking change 2: ContainerRequestFilter

But when I tried to upgrade an internal plugin, we also saw that ContainerRequestFilter that worked in 3.8 suddenly didn't work.
This is much more dangerous, as we use this for implementing a custom security filter. But luckily we had a test which verified that this functionality worked.

Development version and major version

If a series like Quarkus 4.x is considered a development version, then we don't need to bump the major version for every breaking change.

But once it is a LTS (Stable) version, major functionality should not change unless the major version change.

Java LTS versioning

We would also like to look at Java LTS versioning scheme. Everybody knows that they should only use versions 11, 17 and 21.

They should avoid Java versions 12-16, 18-20 and 22-24 in ordinary production applications, as they are more like "feature previews" and meant for the frameworks to implement the new functionality.
(Quarkus should probably build and test against these.)

[hamburml]

Could you please elaborate in which version the ContainerRequestFilter was broken?

Additionally I never thought of non LTS versions as development versions. Development versions are like test builds. In my eyes non LTS Quarkus versions simply do not get security updates like LTS.

[gsmet]

Additionally I never thought of non LTS versions as development versions.

They are not. LTS is an alternative if you want a slower upgrade path that comes with the important fixes and CVE fixes but not with the new features.

Could you please elaborate in which version the ContainerRequestFilter was broken?

As for Breaking change 2: ContainerRequestFilter, did you report it as a bug, was it fixed? Because it looks like something important for us to check.