From d55c6356f0244e5229e846c5118a616c631c1394 Mon Sep 17 00:00:00 2001 From: Josh Date: Tue, 7 Jan 2025 11:03:23 -0500 Subject: [PATCH 1/2] docs(dev): Add backport considerations to development process Signed-off-by: Josh --- .../getting_started/development_process.rst | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/developer_manual/getting_started/development_process.rst b/developer_manual/getting_started/development_process.rst index 9420613a7b7..af2d1cc0658 100644 --- a/developer_manual/getting_started/development_process.rst +++ b/developer_manual/getting_started/development_process.rst @@ -40,6 +40,49 @@ Bugfixes If a contribution fixes a bug that also affects older Nextcloud or app releases, it may qualify for a *backport*. Backporting a fix means applying the change on an older version of the code. Git calls this operation *cherry picking*. +Whenever a critical bug (i.e. security vulnerability) is fixed, it is backported to all applicable major releases and - once merged - published in the next set of maintenance releases for all still supported majors (e.g. 28.0.3 -> 28.0.4). + +Backporting Considerations +************************** + +Major releases that have already been published do not need necessarily need every bug fix. Deciding what to backport is not obvious. There is some judgement involved here. + +Here are some things to consider: + +- Any major release that has not reached end-of-life status usually receives these backported fixes. +- Backporting even the simpliest changes has some level of risk. +- Differences among stable branches - including of shipped and third-pary apps - means there are additional variables outside of the main branch (or even versus the latest stable). +- Fixes often do not have a lot of time in the field (< 4 weeks and it's possible no one has directly interacted with the new code outside of the original developer). + +Showstoppers (never backport things that cause these): + +- API changes [security related matters will be handled on a case-by-case basis since they have a unique priority] + +When assessing whether a bug is critical enough to backport, here are some possible questions to ask yourself: + +- Is it even applicable to a previously published major release train? +- Is that major release train still supported? +- Is it a security vulnerability? [Yes, backport it without question.] +- How well can the change be tested? +- How confident are we in the fix? +- Is the bug likely to impact many users/environments? +- Is there *any* likelihood this change could inadvertenly introduce data loss? +- Is there *any* likelihood this change could inadvertenly introduce a security matter? +- How "hairy" is the change in general? +- Are we willing to support the backport if the change breaks something unexpected in a prior release? +- Can the change be backported as-is or will it require significant reworking? +- Is the bug causing a lot of support requests or bug reports? +- Does the main tracking Issue have a lot of upvotes/subscribers/comments? +- Is it possible to take a "wait and see" attitude about backporting (i.e. continue to test the fix in main/master branch and wait one maintenance cycle to re-evaluate and only backport if further data from the field suggests its important enough and/or low-risk enough to do so)? + +Use your best judgement. + +If appropriate, mention any major concerns in the backport PR so other code reviewers can consider them. + +Ideally, when triggering/requesting a backport, also explain *why* the backport is necessary (if it's not obvious). This will further help reviewers. + +TLDR: Backporting bug fixes to older versions of code can have unintended side effects. Not every fix needs to be backported. Use caution. + Automatic Backport ****************** From dbc460bed7a123545381ed005c942a79874f274e Mon Sep 17 00:00:00 2001 From: Josh Date: Tue, 7 Jan 2025 11:26:26 -0500 Subject: [PATCH 2/2] chore(dev): Add bug vs enhancement consideration Signed-off-by: Josh --- developer_manual/getting_started/development_process.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/developer_manual/getting_started/development_process.rst b/developer_manual/getting_started/development_process.rst index af2d1cc0658..3d53b088914 100644 --- a/developer_manual/getting_started/development_process.rst +++ b/developer_manual/getting_started/development_process.rst @@ -60,6 +60,7 @@ Showstoppers (never backport things that cause these): When assessing whether a bug is critical enough to backport, here are some possible questions to ask yourself: +- Is this really a bug fix? Or is it more an enhancement or a general improvement? - Is it even applicable to a previously published major release train? - Is that major release train still supported? - Is it a security vulnerability? [Yes, backport it without question.]