Explain why we don't want to be in the business of backport certain patches, in the long run. It took me a while to put this into words but I was helped by a similar discussion ongoing in the OpenStack community at the moment [1].
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006220.html Signed-off-by: Stephen Finucane <[email protected]> Cc: Daniel Axtens <[email protected]> --- docs/development/releasing.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/docs/development/releasing.rst b/docs/development/releasing.rst index 86cacb3a..8bb6b314 100644 --- a/docs/development/releasing.rst +++ b/docs/development/releasing.rst @@ -115,3 +115,30 @@ when committing:: When enough patches have been backported, you should release a new **PATCH** release. + +Backport criteria +~~~~~~~~~~~~~~~~~ + +We consider bug fixes and security updates to the Patchwork code itself valid +for backporting, along with fixes to documentation and developer tooling. We do +not, however, consider the following backportable: + +Features + Backporting features is complicated and introduces instability in what is + supposed to be stable release. If new features are required, users should + update their Patchwork version. + +API changes + Except for bug fixes that resolve 5xx-class errors or fix security issues. + This also applies to API versions. + +Requirement changes + Requirements on a stable branch are provided as a "snapshot in time" and, as + with features, should not change so as to prevent instability being introduced + in a stable branch. In addition, stable requirements are not a mechanism to + alert users to security vulnerabilities and should not be considered as such. + Users of stable branches should either rely on distro-provided dependencies, + which generally maintain a snapshot-in-time fork of packages and selectively + backport fixes to them, or manage dependencies manually. In cases, where using + a distro-provided package necessitates minor changes to the Patchwork code, + these can be discussed on a case-by-case basis. -- 2.21.0 _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
