I’d like to brainstorm about switching to LTS releases every 6 months instead of just one per year as currently described at https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices
The rationale is:
- It could be long for our production users to wait one year before upgrading and thus benefit from some new features or less important bug fixes that are not backported. In a cloud world where software is deployed automatically several times per days on cloud instances, releasing a LTS once per year is a bit old school. Ok even twice per year will still be old school but it goes in the right direction
- Most of the active committers work for the XWiki SAS company and that company is providing 2 LTS per year to its clients (they call it a Recommended version FWIW). The way they do it is by asking their committers to do some extra releases in the xwiki open source project + having @ilie.andriuta and Gabriela perform manual testing to ensure the quality. Thus the validation work is already done twice per year and it wouldn’t cost more for most of the current committers compared to the current situation.
How it could work in practice:
- We would still have only a single LTS, i.e. we will backport important bugs only in the latest LTS. Once a new LTS is released, it replaces the previous one.
- When XWiki N.5 is released, that branch becomes a LTS branch
- 2 bug fix releases are done on that branch in 1 month (one release every 15 days)
- When XWiki N.5.2 is released it’s automatically named as the new LTS
- Open question: should we reduce the number of XWiki releases per year by 1 as a consequence or should we do the N.5.1 and N.5.2 releases in parallel to the N.6 release (which could have a lighter roadmap content to accommodate the N.5.x dev work)?
- More upgrades from our users if they want to follow the LTS releases. They’ll be kind of forced to follow up if they want to get the bugfix releases with security fixes and other fixes.
- It means contrib extensions could require more XWiki upgrades too since their parent pom version is supposed to be using the last LTS or older (thus contrib extension developers could update the minimal version more often). Note that this is probably a good thing since it means extensions can use faster new features or new APIs.
I think the more frequent LTS upgrade for our users is the biggest potential issue (the pro side is getting new features and fixes faster while still having a production-ready instance).
The only difference is see from now is that we wouldn’t backport bugfixes in the previous (N-1).10.x LTS after N.5.2 is released. We could also decide to continue backporting in the last two LTS. It’s more work but it’s what we’re currently doing. In that case it would mean having 2 LTS available in the download area and we’d need to modify a lot of places where we talk about the LTS in our docs and processes since that wouldn’t be precise enough anymore (we would need to say mid-year LTS vs end-of-year LTS).
PS: I’m not taking position ATM (even though I sent a brainstorming about it) since I’m currently ambivalent about it. I’d like to hear more from others first.