Our Java support policy at Java Support Strategy - XWiki is missing some details and I’d like to discuss them with you in order to provide a better strategy for us.
Right now we just say that we support LTS and LTS-1 but we don’t mention what we recommend.
I propose that we mention that we recommend the LTS version (the latest one).
This is the new replacement of the old
target parameters and we use it in our top level pom. It corresponds to the java source level we use in our code.
ATM we don’t say anything about it in our support strategy doc, except having a
Source Level column at Java Support Strategy - XWiki that is just indicative.
Actually we do say something about it:
- Java LTS cycle are every 3 years so that seems a good cadence for us to move Java source versions too.
So right now, I understand it as saying that whenever a new LTS is out we should increase the source level we support. For example, when Java 21 is out (Sep 2023), we were using a
release value of
11 and we should increase it to
17 (the next LTS).
Also, it should be noted that Java LTS cycle is now every 2 years, which IMO is too fast for us to follow (more precisely for our users to follow). I propose we stay on a 3 years cadence on our side.
So we need to clarify this to be more explicit:
- Do we agree about staying on increasing our
releasevalue every 3 years to the next LTS from its indicated value (e.g. if the last update of it was on Jan 2022 to
11, then the next update will be on Jan 2025 to
- We also need to decide when we do this and on what branch. I propose that we do it on master, when we start the development of the next XWiki version, i.e. in N.0 where N = XWiki version when we did the last update of the
releasevalue + 3. To be more precise, imagine we’re in Jan 2025 and last time the
releasevalue was changed was in Jan 2022. Master is 17.0-SNAPSHOT at that time. It would mean moving
17for the release of XWiki 17.0.
Note that for 2), there’s the open question as to whether XWiki users will be able to upgrade their java versions that fast. Now, for them it means being about 4.5 years behind the latest Java LTS in practice if they are on the XWiki LTS, which I feel is acceptable. For example:
- We’re in Jan 2025 and master is 17.0. The
releasevalue is increased to
releasewas set to
11in Jan 2022).
- Our LTS users will only use the 17.10.x LTS in Jan 2026 at earliest.
- This means they’ll be forced to switch to Java 17 roughly 4.5 years after it was out (it was released in 2021-09-14).
Right now we don’t say anything about this in the policy. The only consequence from it is that when the
release version changes we also need to update the java version used to build XWiki.
We could align the java version used to build XWiki at the same time as when we change the
release version. This seems the simplest, even if it would be possible to build with a more recent java version and use an older
release value than itself.
Precisely, this means that we would start building with Java 17 only in Jan 2025 (at which date we would be allowed to use java 17 constructs in our code).
WDYT? Do you see any need to start building XWiki with Java 17 earlier?
This is about the versions to run XWiki on.
I propose to keep what we have but make some clarifications. Right now, the page says:
- that we should
Specifically this means working actively to make XWiki work on [the latest release Java LTS] as soon as it’s availablebut it doesn’t say for which branch.
- that as soon as XWiki is confirmed to work with the new Java LTS, then we drop support for the previous LTS (it used to say the following, which I’ve removed when updating the doc recently:
When java 21 is out, and when XWiki is confirmed to work with Java 21, then we will support Java 17 and Java 21, and thus drop support for Java 11).
I propose the following:
- We don’t change the minimum supported version for the currently supported XWiki branches.
- We do a best effort to also support the latest Java LTS for the currently supported branches
- We only drop the oldest supported LTS on master and in N.0 where N = current cycle + 1
As an example, right now we support Java 11 and 17 for all our supported XWiki branches. Java 21 has just been out in Sep 2023. This means that we verify if XWiki 14.10.x, and master work with it (e.g. by having an env test pipeline execute on it). If it does then we update our java support policy to indicate it. If not, we do a best effort to work to support it on these branches. However, when we will work on 16.0, we will drop support for Java 11 for 16.x. However for 15.10.x, we will still support Java 11.
In conclusion this means that we’ll need to support quite a few Java versions (probably 3).
WDYT? Do you see other topics to be discussed here (I see some but I wanted to finish this post which is already long. One topic for later is to have a checklist of actions to do when N.0 is being developed. But we probably don’t need a discussion for this)?