Switching to a LTS release every 6 months?

Development
21

Either we maintain both a LTS and a candidate LTS or we don’t. If we do then it does not make any sense to not expose both.

22

It’s not abnormal to support several LTS (lots of projects do that, for ex Tomcat, Jetty, etc) with bug fix releases for the LTS of each branch/cycle.

23

Not sure what is your point, you seem to be the one complaining about supporting several LTS right now :slight_smile: All I’m asking here is to make it as easy as possible to choose which level of LTS you want to install.

24

I’m reviving this thread as I dropped the ball…

I’ve re-read it all and I think we basically have an agreement and the only remaining point was the introduction of a new debian repository. See below.

Yes I meant per cycle

Ok to add a new Debian repository and my naming preference is lts-candidate. Users who want both LTSes will need to have the 2 repos in their setup on Debian.

WDYT of a definition of the Candidate LTS like this:

The difference between the current cycle Candidate LTS and the previous cycle LTS is that the Candidate LTS allows users in production to use the newest features of XWiki. It’s super stable but the newest features will have less time to mature than what you’d find if you waited for the current cycle LTS, at the end of the year.

Recommendations:

  • If some of the new features present in the Candidate LTS are important for you, we recommend that you upgrade to it.
  • If you’re starting with a new installation of XWiki (i.e. you’re not upgrading), we also recommend that you start with it, as it contains the latest and best features.
  • If upgrading XWiki is hard for you (e.g. lots of customizations) and the new features are not of a particular interest, then we recommend that you stay on your current LTS and wait till the next LTS (at end of year).

We will need to update the following docs:

This thread was a brainstorming and if I get a few approvals I’ll start a VOTE for it since I believe we need that as it’s an important decision. So please, speak up now if you’re not in favor of this :slight_smile:

Thx

25

+1 to start a VOTE

But since there were several variations, it’s not fully clear to me what is the current state of this proposal.

When do we start the next official Candidate LTS ? 16.4.x is currently kind of it technically (but only for XWiki SAS) and I would not be a huge fan of also support a 16.5.x Candidate LTS (since my understanding is that the current proposal is x.5.0). Or do we start this only with 17.5.0 ?

It’s not really clear to me what is the current proposal regarding the support time for each kind of LTS. I was thinking about:

  • Cycle LTS: until the next Cycle LTS starts (so same as now, about 1 year).
  • Candidate LTS: until the next Cycle LTS starts (I feel it does not make much sense to keep supporting a Candidate LTS if there is a higher Cycle LTS). That would suggest that the first half of the year, the Cycle and Candidate LTS would actually be the same thing.
26

Just from a admin/user point of view: „candidate lts“ is confusing as it suggest it’s a candidate with the complete featureset and maybe become 1:1 the release just like an release candidate is (which is not the case if I understand you correctly).
Intermediate lts or Midyear lts or something similar would probably be a better naming.

27

Indeed, it’s not the case, there’ll be more improvements and features added.

Thanks for the feedback, it’s a good idea. Both names sounds good to me with a small preference for “Intermediate” as it reflects more the fact that it could be less polished than the end of the year LTS.

28

Sounds like we kind of forgot this again, we should start a vote IMO.

29

For sure it needs to be the same version. I proposed N.5.x above but maybe it should actually be N.4.x since the experience shows that’s what has worked the best over the years, and it takes time to stabilize a branch, and thus to have it midyear as an official LTS, we will need that additional month (for the 2 bug fix releases leading to N.4.2, ie leading to end of June).

We can start advertising 16.4.x. as our Intermediate LTS.

Yes, agreed.

  • LTS → once every year (same as now, at end of December)
  • Intermediate LTS → exists until the LTS is released.

Sure, I can start a VOTE but first I’d like one or 2 agreements to use “Intermediate LTS”.

Thx

30

I read the thread again since the proposal changed a bit since the beginning :slight_smile:

I’m definitely +1 for this.

+1

+1

+1

31

I’m fine with “Intermediate LTS”.

32

I like Candidate LTS better, but Intermediate LTS is also ok for me.

33

Do we have some stats regarding how often admins upgrade XWiki? Does it really happen more than once per year?

I’m fine with “Intermediate LTS” but I think it would be good to track how many admins upgrade to this type of version to see if it’s worth the effort.

Thanks,
Marius

34

Actually, we do have some stats, with active installs (we have the info at least but we don’t have a dashboard with info readily available, @ludovic might have this stat).

IMO the fact that the XWiki SAS company (which has started this idea of a mid-year LTS) did this, is the answer to a real need. AFAIK they had regular requests from clients (in production) to upgrade and they were telling them that they had to wait for up to one year before upgrading and the clients were not happy.

It doesn’t mean that everyone will upgrade all the time but that when you do want to upgrade you need to wait only a max of 6 month (vs max of 1 year otherwise).

Note that the upgrade use case is only one use case. The other use case is someone not having installed XWiki yet but wanting a production-ready version. It’s a pity that they cannot use the recent features developed that are ready and that they have to use features that are up to 1 year old.

Last, related to the effort part of your question, I think we need to spend more time on our dev practices to reduce the time it takes to perform a release (and automate the release process more). We’re in 2024 (soon 2025 ;)) and I believe, we should ideally be able to release a new version whenever a bug is fixed, or a new feature is out (with feature flags for features not good enough yet). There are companies out there which perform several releases every day to a cloud. I think we need to work towards continuous delivery and reduce our delivery costs.

If we can release fast, then if there are regressions, we can also re-release fast (ofc we should continue to add automated tests). For this to work, we also need that upgrades are done easily so we also need to work on this. We worked on it, but we’re far from having reached an optimum.

Thanks for the OOB question :slight_smile: It’s worth asking ourselves that question.

2 Likes
35

I hope you don’t mind a post by ad admin :slight_smile:
And there’s a bit of a critics about the 15.x, I hope I do not sound too rude; apologizes in advance, anyway.

I administer our wiki instance, we use it only in our IT department, so each user is tech savvy and we don’t really use all the new features every time, and we are just a bunch of users.

Plus, I only run a single production instance, I can’t afford any critical bug, regression or whatever would require me to have our instance restored to a previous snapshot - much because the database is on a secondary host, together with other schemas.

So I carefully pick the version and time to upgrade. I started with an LTS (14.x IIRC), that I update two to three times per year. When a new patch version comes out, I usually wait around one month to see if another version is released which fixes any regression or any other bug in the latest one.

During the last months of 2023 probably, I evaluated upgrading to 15.x (from 14.x), then I looked at the release page of several versions:

While of course I appreciate the number of new features that were introduced, for our needs the number of regressions listed in those pages made me decide to not to run the risk of any instability (remember that we don’t make use of all the features that get added), so I waited for the 15 LTS.
IIRC I upgraded when 15.10.4 was out, so not even the first LTS.
And with the following upgrade we jumped at 15.10.11

Maybe 15.x was particularly unfortunate, but if you add new features with each minor version, that could mean that the mid-year LTS (which would have been 15.5 if I’m not wrong) would have required lot of fixes before being stable - here by stable I mean with few bugs fixed or at least discovered.

So up to now I favor the mid-LTS, I just hope it won’t mean having to wait for 15.5.8 before upgrading to the 15.5 LTS

Not really a stat :slight_smile: but I do it two to three times per year - manually installing the WAR package in Tomcat + MySQL.

Would be cool, but the most important reason I do not update more ofter is configuration editing: I moved the config files under /etc and to be sure there are no conflicts, after each upgrade I diff the new vanilla config file with the edited one from the previous version.
If there’s nothing very different I just edit the changed lines to copy over the previous values.

That, plus download, backups and other housekeepings takes a couple of hours.

3 Likes
36

That’s actually a good point: in current process with XWiki SAS we’re waiting a full run of tests before declaring the version is “recommended”. And sometimes we decide to move from N.4 to N.5 for the recommended candidate because it’s not stable enough (was the case during 15.x cycle).
For LTS we declare LTS after the second bug fix release (so N.10.2): we should clarify at which point do we flag an intermediate LTS as such, because it’s probably indeed dangerous to release N.4.0 and declare it candidate LTS right away.

37

And that’s not exacty what has been proposed above :slight_smile: :

Basically it’d be the exact same process as for the LTS.

2 Likes
38

Closing since I’ve now started a VOTE on Introduce the concept of "Intermediate LTS"