Keep LTS as stable as possible and allow releasing even when issues remain

Development
#1

Hi devs,

I’ve had a discussion with Simon on the chat and it appeared that we need a proposal to make sure we agree about a situation.

Situation:

  • Our 12.10.3 LTS has several blockers reported for it (including important ones, not just regressions).
  • We haven’t released a 12.10.4 for 2.5 weeks now even though we have fixed important bugs and blockers already.
  • The reason we haven’t released a 12.10.4 already is because there are still known blockers not fixed in the 12.10.x branch.
  • Since 12.10.x is the LTS branch and it’s supposed to be super stable, we need to keep it as stable as possible, all the time. Our users use it in production every day & the branch represents the quality of XWiki.

Proposal:

  • If we have important bugs fixed on the LTS branch, and we see that it’s taking time to fix other known important bugs (including blockers), we should be able to still release a new LTS release (with information in the RN about the remaining issues), so that new users coming to XWiki will be able to experience a bit less bugs on the LTS version. For existing users (of say 12.10.3), it’s up to them, when 12.10.4 is released to decide to upgrade or not. Even if they don’t read the RN, at worse they’ll have spent some extra time doing the upgrade even if issues still remain (but they’ll have a more stable version globally).
  • It’s up to the core dev team to decide when to release precisely but keeping in mind that LTS must be stable at all time and thus releasing sooner than later is critical for the LTS branch.

WDYT?

Thanks

1 Like
#2

Note: Right now we have no documented rule (AFAIK) about not releasing when there are blockers so if we agree about the above I’ll document that rule + document the exceptions to it.

#3

Actually we have, but indirectly, in the release plan, for example: https://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlan13.0 It says “Verify that there are no open issues on JIRA for version 13.0 and that there are no open Blockers”.

#4

I agree with that. Now IMO there’s two problems for taking such decision:

  1. we need a sooner ownership of the bugfix releases. Right now we decide who performs the bugfix releases pretty late. It would be easier to take the decision if a RM is assigned very fast for the next bug fix, especially for LTS.
  2. it might be difficult to know that it takes time to fix other bugs, so I guess it would be the RM decision to perform the release even if there’s remaining issues, when they see a spot for doing it. I guess it would only make sense if there’s a blocker/critical issue already fixed.
#5

Hi Vincent, I think you need to be a bit more precise.

Here’s the list https://jira.xwiki.org/issues/?jql=project%20in%20(XWIKI%2C%20XRENDERING%2C%20XCOMMONS)%20AND%20priority%20%3D%20Blocker%20AND%20fixVersion%20%3D%2012.10.4 . It shows 2 blockers.

There are 2.5 weeks since 12.10.3 was released, but the two blockers listed above have been fixed on February 3rd and 4th, which is 3 working days ago.

There was only https://jira.xwiki.org/browse/XWIKI-18290 remaining, which I could have closed yesterday if nexus.xwiki.org wasn’t down for most part of the day.

How many days is OK to wait after a blocker is fixed on LTS? In this case we waited 3 days (and it could have been 2). I guess you think this is too much. So you propose to wait at most 1 day?

Thanks,
Marius

#6

Actually they even have been both found February 3rd.

#7

The discussion was not about defining a timeframe but about allowing to release a new LTS version whenever some blockers are already fixed, without waiting for more blockers to be fixed. It doesn’t mean enforcing a release as soon as a blocker is fixed but rather that we allow ourselves to bypass the rule “don’t release when there are open blockers” in this LTS situation, when we think it makes sense (adhoc judgment). This was the whole discussion with Simon who was saying that we couldn’t release the new LTS because there were still open blockers.

#8

+1 for this.

1 Like
#9

+1 too

#10

+1, thanks