מדיניות בחירה מדויקת של גרסה יציבה נוספת

סיכום מבוסס בינה מלאכותית

The discussion revolves around establishing a clear policy for cherry-picking commits onto the stable branch of Discourse plugins, starting with the Custom Wizard plugin. angus notes that some forum admins prefer stable over tests-passed but are concerned about unexpected commits being cherry-picked outside of formal releases. The question is whether there’s an official policy on what qualifies as an “extra-version cherry-pick.” Falco clarifies that only security patches and critical bug fixes are typically backported to stable, with a brief exception in the first weeks after a new Discourse release, when minor bug fixes may also be backported to create the first point release. This approach aligns with a historical precedent referenced by eviltrout, who noted that shortly after a stable release, a wave of reported issues often leads to broader backporting. The goal is to balance stability for plugin users with the need to address urgent issues, while ensuring admins understand what changes to expect on the stable branch outside of versioned releases.

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”)?

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: