There is one thing that feels like an inconsistency to me: from what I understood, you propose to drop support for Java 11 in XWiki 16 but still keep the source version to Java 11 (since the move to Java 17 would be in XWiki 17).
I really don’t see the point of having a source version different from the minimum supported version, they should always be equal for a given branch, otherwise it’s way too hard to understand.
About the 3 years to switch the source version (and minimum supported version), I honestly don’t know if it’s the best value or not. But I feel it would be much simpler to have a rule based on what is the current LTS when starting a cycle (which, in practice, means switching every 2 years). And LTS-1 (so the current rule, XWiki 16/2024 for Java 17 and XWiki 18/2026 for Java 21) does not seem that bad honestly to me (Debian dropped support for Java 11 6 months ago). We could also try LTS-2 (so XWiki 18/2025 for Java 17 and XWiki 20/2027 for Java 21) but I’m afraid it might be a bit too far behind (the current Jetty stable branch, 12, started 3 months ago, already requires Java 17).
I think we agree. What’s important is to decide what’s our strategy for recommended is and my suggestion is to use the latest LTS we support (per branch since we won’t have the same level on all branches). It’s not because a new LTS of Java is out that we support it immediately (see the other points about that). We support it for a branch only when we have proven that XWiki for that branch works with it.
Definitely. For example, I’m going to add a test env to test XWiki with Java 21 right now, even though we’ll not move to release = 21 before a long time.
Good point. We need to decide. Support means testing that XWiki works 17 and 21 in XWiki 16. It doesn’t mean anything about the source level, which could stay on 11 and be changed later. Now I understand your point, which is basically: why not continue testing XWiki 16.x with Java 11 (in addition to 17 and 21) since the source level is 11. I think we could do that, it’s just more work and bigger costs (since we need more agents globally since we need to test more builds on java 11). We could decide that we’ll only use Java 11 for some test env that execute once a week for example. I guess that could be enough and would mitigate the extra cost.
In this case the strategy would be to drop support for a Java version only when we change the release version.
Yes, and that’s what I wrote initially before realizing that the Java release cadence had moved from 3 years to 2 years. I really think 2 years is not doable for our users, especially our users using XWiki in a business environment.
What do others think about the cadence of upgrading our minimal java version? Do you think 3 years is good or should we move to 2 years (or even 4 years) ? Note that the more year we add; the more cost we have to run our builds on all the java versions in between and ofc the more the devs have to wait to benefit from the language new features.
Regarding the Java syntax to use, if LTS branches are in a different versions than master, this can lead to issues when cherry-picking.
So another option is to only allow the use of the syntax of the older java version we have on a supported branch.
Interesting. However, that would make moving to an increased release value, a year later if I understand correctly (the time for the XWiki LTS branch to change). Thus moving from 4.5 years to 5.5. Or we change the cadence to be 2 years (as Thomas wanted) and not 3 but with this additional rule which should keep the real user cadence to 4.5 years.
WDYT?
PS: haven’t thought through all this. I’d need to create an example to make sure that what I said is correct.
Note that this is already what’s happening in practice. This is a remark that has been made initially by @surli on this proposal, regarding the use of the var keyword.
I’m not so sure this is the right way to look at this. Using Java LTS-1 at the beginning of a cycle means that when the cycle becomes the XWiki LTS we are 3 years behind the current Java LTS which I think is acceptable. And frankly that’s actually what you proposed too in practice since I don’t see why people would use XWiki with an unsupported version of Java, whatever we put as source version. I’m mainly proposing to align the source on the minimum supported version, which is a lot easier to understand for everyone.
What’s the cost for the infra team of upgrading Java?
Upgrading the OS used on the server running XWiki? This shouldn’t be a problem when XWiki runs inside a (Docker) container right? But I guess most installs don’t use containers. You still need to upgrade your OS from time to time (e.g. to get security fixes), but probably most OS providers offer multi-year LTS support (I see Debian has 5 years LTS)
Conflicts with other Java applications that run on the same server? But the infra team can install multiple Java version no? (unless more recent Java versions are not available for the old OS you’re using)
Having to wait 4.5 years to use some “new” Java syntax feels a lot. I haven’t followed very closely what new Java versions bring in terms of syntax and APIs, I guess most of that is not really critical / blocker for us, but it’s enough to have one or two that are useful to make wait painful .
As a man responsible for a consequent amount of XWiki instances in the XWiki SAS Cloud, I do not really mind about the version of Java we use, as soon as:
the version is available on popular Linux distributions by default (especially, on Debian Stable).
the version is maintained.
When it comes to upgrading XWiki, it doesn’t pose a problem for me or our Infrastructure team to upgrade the operating system if needed. We generally aim to utilize the latest stable versions of the OS, so the upgrade aligns with our usual practices.
I read the whole thread but I didn’t do all the math and timelines in my head. I am trying to answer with what I’d expect to have rather than with the rule that would result in that.
the way that I am looking at this is:
I’m a self-hoster of XWiki
I am upgrading to XWiki LTSes or mid-cycle versions with bugfix releases - once or twice per year
how often I also need to “bump my infra” so that XWiki still runs?
I think that if I need to manipulate my infra every 2 years or every 3 years it’s acceptable (both are actually acceptable). If I cannot manipulate my infra that often, I may not want to manipulate my XWiki that often either…
Now, the next questions I need to ask myself is how special that infra would be (downwards or upwards) - if I’m not running XWiki in a container:
honestly, I would say that the most frequent case here is servers running Debian, so it would be ideal if we could have a smaller gap with Debian: not using a version that’s already not supported anymore by Debian for a recent version of XWiki but also not requiring a version not yet available on Debian for an XWiki LTS. I don’t know the numbers, so you’ll need to help me here.
I would say that if this is the case, we cannot to much about it, as it can be very diverse. It’s not the 2 years to 3 years difference that will be able to cover enough of the cases that can occur (what other applications?) in order for the XWiki project to be worth making an effort in this direction.
I would also prefer actual numbers for some of the support strategies. We can keep the strategy also as a “rule” about what we plan to work on in terms of support in the future, but as announcement to the users it would be great to have the actual numbers for all released versions of XWiki elsewhere than in the test results (same for the database engines and servlet containers).
ok so it seems all people who answered think it’s ok to follow the Java LTS cadence of 2 years (and not do 3 years). Taking into account all comments, here are 2 proposals:
Proposal 1
We recommend to our users to run XWiki on the latest Java version we support.
We follow the Java LTS cadence (every 2 year), which means that at the beginning of every 2 XWiki cycles, we drop the oldest Java version that we were supporting, and at the source level we upgrade it by one version. This means for example:
In XWiki 16.0 (2024), we drop the support of Java 11 and support Java 17 (new source level) and work as fast as possible to support Java 21 in 16.x. We support Java 11 & 17 for XWiki 15.10.x.
In XWiki 17.0 (2025), we continue to support Java 17 & 21. We support Java 17 & 21 for XWiki 16.10.x.
Java 25 is out in September 2025
In XWiki 18.0 (2026), we drop support for Java 17, continue to support Java 21 (new source level) and add support for Java 25 asap. We support Java 17 & 21 for XWiki 17.10.x.
Proposal 2
Variation to decide (suggested by Manuel above to avoid cherry-picking issues):
We recommend to our users to run XWiki on the latest Java version we support.
We only upgrade the source level when the LTS stops supporting the version. For example:
In XWiki 16.0 (2024), we drop the support of Java 11 and support Java 17 and work as fast as possible to support Java 21 in 16.x. We support Java 11 & 17 for XWiki 15.10.x. Source level = 11 for 16.x.
In XWiki 17.0 (2025), we continue to support Java 17 & 21. We support Java 17 & 21 for XWiki 16.10.x. Source level = 17 for 17.x AND 16.10.x.
Java 25 is out in September 2025
In XWiki 18.0 (2026), we drop support for Java 17, continue to support Java 21 and add support for Java 25 asap. We support Java 17 & 21 for XWiki 17.10.x. Source level = 17 for 18.x
Source level = 21 for 19.x AND 18.10.x.
Pros of proposal 1:
Faster to be able to use the new construct of the Java language
Pros of proposal 2:
Less potential problems with merges on the LTS branch
What do you prefer?
On my side, I have a preference for proposal 1, even if it could be harder for merges (but the build will quickly find the problems when that happens). Basically I’d prefer favoring the use of new constructs sooner. Also, it’s not great to change the source level in a LTS.
+1 for proposal 1, it’s just a lot simpler to understand for everyone, and I really don’t like changing the source level in a LTS x.10.y…
-0 for proposal 2
Now, for me, the rule discussed here mainly make sense for the minimum supported version and the source version.
I think we need a different logic for the maximum supported version (one not based on the change of cycle in XWiki). For example, I’m not sure it makes much sense to never support Java 21 in 15.10.x. After all, we felt the need to support Java 17 in 14.10.x (contrary to what you indicated in the proposal).
-0 for proposal 2 as it does not feels right to change the source level of a LTS
+1 for proposal 1, with a best practice to avoid using “new” code constructors on code that has a risk if being cherry-picked to LTS (what we already do for APIs for instance anyway).
yes, I agree that we should not have any constraint for the max supported version. It’s a best effort to support the max # of java versions. This is non-controversial and I’ll add it to our java support page after we agree.
PS: I’m not sure where I indicated something different.
EDIT: I’ve just realized that I’ve read Java Support Strategy - XWiki wrongly Editing the proposal above as it was supposed to say XWiki 14.10.x (2022) supports Java 11 & 17. Thx
.