diff options
| author | Stephen Finucane <stephen@that.guru> | 2019-05-14 15:56:53 +0100 |
|---|---|---|
| committer | Stephen Finucane <stephen@that.guru> | 2019-05-24 15:49:21 +0100 |
| commit | 8c8b4b96a251deed6a48349e29e6043d2903daec (patch) | |
| tree | e583dfad1ec66940b692a10f6121a3c9ddf98b18 /docs | |
| parent | 0c7d45e35fe409dd056ccc4558808a8e97ffaf0e (diff) | |
| download | patchwork-8c8b4b96a251deed6a48349e29e6043d2903daec.tar patchwork-8c8b4b96a251deed6a48349e29e6043d2903daec.tar.gz | |
docs: Document backport criteria
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 <stephen@that.guru>
Acked-by: Daniel Axtens <dja@axtens.net>
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/development/releasing.rst | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/docs/development/releasing.rst b/docs/development/releasing.rst index 86cacb3..8bb6b31 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. |