Stable extra-version cherry-pick policy

Pavilion is considering officially supporting stable for some of our plugins, starting with the Custom Wizard plugin.

Various folks have been asking for an alternative to tests-passed support for some of our plugins (particularly the Custom Wizard pugin) for some time, and it’s a combination of critical mass in requests, plus the plugin now being in a reguarlized state (tests coverage, CI, semantic versioning etc), that we’re considering this.

Some forum admins who are looking for something more stable than tests-passed support in the plugin pin their forums to specific versions, one at a time. One of the concerns that group of forum admins have expressed with adopting stable is that additional commits get cherry-picked onto stable outside of specific releases.

If those forum admins were to adopt stable as well (in line with the plugin) they’d be adopting those additional commits outside of regular versions. The cherry-picking policy / approach would also affect the way we maintain the stable branch on the plugin(s).

Is there a poicy about what kind of commits get cherry picked? I have been under the impression that commits cherry-picked onto stable outside of specific versions are (now) limited to security patches and bugfixes, whereas in the past the approach was sometimes more liberal.

Is there a current policy on what gets cherry-picked onto stable outside of versions (“extra-version cherries”)?

7 Likes

Only security commits/bugs are backported into stable, with the exception being, in the first weeks after a new Discourse release, we will backport smaller bug fixes into stable to create that version first point release.

Basically:

4 Likes