Switching to a LTS release every 6 months?

Hi devs,

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 :wink:
  • 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)?

Consequences:

  • 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).

WDYT?

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.

Are you talking about new extensions here ? Because for existing extensions, having more LTS should not have any kind of impact: the XWiki version required by an extension is supposed to be upgraded only if the extension really needs it.

I agree that either there is only one LTS or we have two different names and I don’t think “mid-year LTS” is different enough.

As a XWiki SAS dev I don’t mind continuing supporting 3 branches (i.e. keep 12.10.x). I have the feeling that stopping the support of a something we call LTS after 6 months which is essentially what we are talking about here is a bit harsh.

In summary, I’m +1 to make official what we are already doing on XWiki SAS side with 3 supported branches since it would make my life simpler and -0 to stop supporting what is currently called LTS (even if it would make my life even simpler :slight_smile: ).

The “really needs it” is quite subjective. For ex, I’ve upgraded the parent pom several times for build reasons (to be able to have Docker tests for ex). The only rule that exists is that extensions must work on LTS releases. That’s the only thing we can rely on. Thus if there are more LTS releases, it most likely means more recent parent POM changes and thus needing for users to upgrade more recently their XS version. It may not be a lot but I’ve the feeling it’ll go in this direction.

FTR, I’d really like to avoid introducing a new concept. For me it’s either “stable” or “LTS”. Any other name will be confusing and make things too complex IMO.

In this case, it means this proposal should be dropped and we should continue what we do now IMO. I’m fine with that BTW.

For me if we don’t call it LTS and if each LTS doesn’t replace the previous one (ie we stop supporting the previous one), then I’d drop this proposal and I’d be in favor of continuing as we do now).

Let’s see what others think.

Thanks for your reply Thomas.

Honestly I really doubt your practice is very common, if you look at existing extensions you won’t find many which depend on the current LTS and you will find many which have very old XWiki versions as constraint, even very active extensions.

Thanks for starting this thread, I took time to answer since I’m really mixed. On one hand I’d like that we support less branches and we accelerate bringing new features with shorter LTS, and on the other hand it feels a bit dangerous to have LTS of 6 months on our stability.

An aspect we could check is if it would speed up the testing process: right now there’s manual tests performed by XWiki SAS on the 3 branches, if we have only 2 I guess we might have faster status and maybe a better handling of the stability on the long run?

Now personally as a start, I’d be very much in favor of at least make official on XWiki.org the mid-year version XWiki SAS ask us to maintain. It would be easier for the communication of XWiki.org, when we advise to use a version over another on the forum for example etc. And maybe doing that for a year or two could show us if people are moving fast to the mid-year version or if they prefer to stick to the LTS.

My issue with making the N.5.x LTS is that I don’t think we have enough time to polish the features we introduce in the first part of the year. From past experience I think we need a year for that. So I’m leaning towards continuing what we’re doing now.

A counter-argument for that is that we (often?) provide in first part of the year refactoring of some features that are not cherry-picked on LTS and that fixes some bugs including important security issues. So on a security point of view, it might be interesting for users to have this information that a version is recommended.

Note that I’m not talking necessarily about making this version a 6 months LTS. I’m more talking about keeping to work the way we do, but advertising about this mid-year recommended version. It would also avoid some confusion when XWiki SAS committers are releasing those versions and making them available on official docker repo for example (see the discussion we had about it yesterday on the chat: You're invited to talk on Matrix)

What does that mean precisely? There’s no concept of “recommended version” on xwiki.org, and personally I wouldn’t introduce a new concept (too complex and confusing - why would a LTS not be recommended, what about stable why wouldn’t we recommend it either, etc).

Reading the full thread, I see the following possibility to reconcile everything said:

  • Announce the mid year version as a LTS version (but name it “Candidate LTS” on the download page, see below)
  • Support 1 LTS version per branch and a max of 2 LTS versions in parallel (more work but it’s what XWiki SAS committers do already, but not necessarily what all xwiki.org committers do, so more work for them).
    • This means that the mid year LTS doesn’t replace the previous end of year LTS since they’re on different branches
    • However once the end of year LTS is released, it replaces the mid year one since we support only 1 LTS per branch.
    • It also means that on the download we have one more entry around the middle of the year: the previous branch LTS and the new mid year one for the new branch. Makes it slightly more complex for users to decide what to pick so I’d propose to name it “Candidate LTS” and in the desc, we would mention that it contains more new features and bug/security fixes than the previous branch LTS but it’s a bit less stable as it has had less stabilization time, but we still recommend it for production usage.
  • We also need to decide when the mid year LTS becomes a LTS and visible on the download page. I would do what I proposed originally:
    • 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 a LTS and made available as a “Candidate LTS” on the download page. Note: This means that N.5 is just a standard stable release and N.5.1 is made visible on the download page only if it’s released before N.6 is (which it should normally since it’s supposed to be released 15 days after N.5 whereas N.6 is released 30 days after).
  • It also means changing Support (XWiki.org) and increasing the number of supported versions by 1 (3 ATM, would be 4).

WDYT?

General thoughts:

  • I don’t like too much having 2 LTS/recommended per year as I think it slows us down (release time, backport time, testing time, etc). However I recognize that having to wait 1 year for a feature is sometimes too long.
    • OTOH it could have been an advantage of a company such as XWiki SAS to provide this added value without the xwiki.org project offering it.
    • That said, the 2 LTS should move our users faster towards using the latest features/code and that’s a good thing for xwiki.org as it should get us more feedback about the new features and less users on older versions.
  • Ideally all our releases should be LTS-quality if we had a build good enough to validate that. This is probably what we should aim for on the long run. When the quality is checked in the build automatically it doesn’t cost more and we can have only LTS… This is potentially just a dream though :wink:

I’d propose to name it “Candidate LTS” and in the desc, we would mention that it contains more new features and bug/security fixes than the previous branch LTS but it’s a bit less stable as it has had less stabilization time, but we still recommend it for production usage.

I like the concept of candidate LTS and it fits well with the description you provided IMO.
So +1.

I guess you meant “per cycle” (a “branch” is 13.5.x and a “cycle” 13.x).

I’m fine with “Candidate LTS” naming. Just need to decide what would be the one word version of it to use as docker tag and for the dedicated virtual Debian repository for example.

No obvious idea on my side, I can think of:

  • candidate-lts
  • lts-candidate
  • clts (not a fan)

For me it’s a LTS and “candidate” is just a qualifier (mostly for documentation). I didn’t want to introduce a new concept. So I would make it available as a LTS in Debian too. Is the issue that user will get upgraded to it automatically if they’re on the LTS and they do an “apt upgrade”? Is that a problem?

For me it’s not a problem. It’s a LTS and it’s normal that users should be upgraded to it. If it’s an issue then I’d propose to drop the “candidate” part. I’m really adamant that we don’t introduce a new concept as IMO it breaks everything otherwise.

I don’t understand the question. What you are proposing is essentially to not have any LTS repository anymore and only a candidate LTS one. But again this is not a Debian specific thing, should I understand that you are proposing to set the lts tag on the 13.4.x branch instead of 12.10.x in official-images/xwiki at master · docker-library/official-images · GitHub ?

For Docker I would see:

  • lts tag pointing to 12.10.x
  • 13-lts tag pointing to 13.4.x
  • 12-lts tag pointing to 12.10.x

Can this be done for debian too?

As a second choice, I don’t think it would be a big problem to also have (it would actually move more users to the new LTS):

  • lts tag pointing to 13.4.x
  • 13-lts tag pointing to 13.4.x
  • 12-lts tag pointing to 12.10.x

I don’t understand this part.

My point is that some users will want to install “whatever is the current LTS excluding candidates” and some would like to have “whatever is the current LTS including candidates” so we would need to have two different tags/repositories for those two use cases.

If you follow the docker tag proposal I made above you can get these 2 use cases:

  • first option: if you don’t care, you get the 12.10.x as the lts. If you care you use 13-lts.
  • second option: if you don’t care, you get the 13.4.x as the lts. If you care you use 12-lts.

It works for docker tags, but not for Debian repositories. I agree with Thomas that for this one, we might need some new repositories to allow the different usecases. I see two solutions:

  1. we put candidate LTS in the LTS repository too, then we provide a new repository for end year LTS only (and we need to find a name for those)
  2. we don’t put candidate LTS in the LTS repository, and we provide a candidate LTS repository

Note that solution 2 allow people to get upgrade for both LTS and candidate LTS if they had both repositories on the system, so I think it’s the best option here.

For me we should have only once concept: the LTS one. And thus have only 1 repo (the LTS one). Otherwise it defeats the advantage of having users use the mid year LTS and we do extra work for not much (not enough). What’s the point of doing all the work of “recommending” the mid year LTS if we don’t believe in it and don’t consider it a LTS?

What you listed here are more workarounds than tags expressing what I indicated.