When to drop the previous LTS branches when a new Cycle LTS is released?

I have now discussed with @ilie.andriuta and @atarata and I’d like to propose an amendment to the proposal above as I don’t really like the fact that we wouldn’t be able to label a release as LTS before ManualQA has validated it and found no blockers in it. I feel this is too long and will take us towards mid or end of January before we can label the N.10.x branch as LTS.

This would be a pity since the reason we moved to doing 2 bugfix releases in December was to be able to have a LTS by end of the year.

So the proposed amendment is:

  • We keep our current process as written on https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices/ and mark the LTS when N.4.2 and N.10.2 are released
  • Manual QA does the testing as indicated above, in the priority order mentioned above
  • Once Manual QA has validated a version (and no blocker has been found in it), we indicate it in the Release Notes of that version + on the download page we add some QA badge next to the version (with some hint explaining that the version has been validated by Manual QA), or simply some text after the version content list.
  • We don’t close the previous Cycle LTS branche + last intermediary LTS and continue to backport important bug fixes on them, until Manual QA has approved the new Cycle LTS. At that time, we do one last release of the 2 branches and drop support for them.

WDYT?

Thx