Allowing core committers to release official bugfix releases of XWiki branches

Development
1

Hi devs,

A few days ago I launched a vote to allow some core committers to perform non-official security bugfix releases for the N-P.10.x branch (P > 1). See Allow ad-hoc security branch releases

However, while trying to implement that we found that it wasn’t the right call as it’s difficult to have some releases that are not official. Some pain points:

  • The name “XWiki X.Y.Z” shouldn’t be used for non official releases as it’s reserved to official release of the xwiki.org project
  • Adding the release version to github advisories was a bit sketchy (it’s stretching the line to add non official releases of XWiki there)
  • Including some non-official releases in the computation of the embargo period was also sketchy

Thus this vote is replacing the one from Allow ad-hoc security branch releases and proposing to amend the Governance of xwiki.org as follows:

  • Any core committer could decide to maintain any XWiki branch for some time, in order to backport bug fixes.
  • The core committer wanting to perform a release of that branch must send a VOTE for each such release they want to do. This is the way for other committers to provide an oversight, and have a say about it. That part is important since an official release means an impact for the whole project. For ex imagine that the content is of not good enough quality, or other problems.
  • These releases are done following the standard release process of the XWiki product.
  • If the released branch is older than the last cycle LTS, then the releases should not be advertised (no mention on the download page, no wikipedia/wikimatrix updates, no mastodon post). That’s because we don’t want to promote old releases, as we want our users to use the latest versions and upgrade more often.
  • Since this is following the standard release process, as any normal release, this means that these releases are included in the security advisories (if there are security issues fixed in it).
    • In addition, if the release is done within the original embargo period of the other official branches, then a new embargo date is computed (within the limit that the new embargo period can never be more than twice the original embargo period. To protect against public disclosures that would arrive too late).

Please cast your votes. 72 hours standard period.

Here’s my +1

Thanks

2

+1, sounds good to me. The only question I have is if this (in particular the vote) would also apply to bug fix releases for the current stable version that we sometimes do when we, e.g., discover a severe regression.

3

I don’t think we need it as it’s covered by https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices/#HReleaseCyclesandReleaseStrategy and under the “supported branches” from https://www.xwiki.org/xwiki/bin/view/Main/Support#HSupportedVersions

So it’s basically something already planned in our standard support. The proposal here is for releases outside of that standard support.

Thanks

4

+1 thanks

5

+1

6

+1

7

+1

8

+1

Thanks,
Marius

9

The VOTE is passed: 7 +1, no 0, no -1

I’ll document asap.

Thx

10

Documentation has been updated at https://www.xwiki.org/xwiki/bin/view/Main/Support#HSpecialCommitterVersions (I’m not 100% sure it’s the best location for it but the Governance page is also not the right place and the Security Policy neither, maybe it would need to be split into several parts located at different places).