Document the procedure for TYPO3v4 "multiple branches" from non-technical perspective
Several discussions started in the typo3-core mailing lists raising the question about how to deal with the "backports" in our TYPO3v4 core branches. See threads:
- "[TYPO3-core] Gerrit submission process for multiple branches" from 30.10.2011 (Francois Suter)
- "[TYPO3-core] Change procedure revisited" from 19.11.2011 (Jigal van Hemert)
for a more in depth discussion about it.
We need some "official" documentation on how our team works, who has which responsabilities and what to expect from the core team, from the release managers (and what not to expect).
What we already have¶
- A technical documentation on backporting a change to other branches
- The rules:
- first "push" the request to latest version where the patch applies (in general this should be "master")
- already include "Releases:" tag in the commit message indicating to which other releases this fix will apply
- only after the full review and merge has happened there, the backporting begins
This is where the "gray zone" starts, because it's not documented who / when / why should do the backporting and what has to be considered while doing that.
What we need¶
Starting with these facts we should document the whole process. Following Jigal's suggestion of using the clear terms "COULD", "SHOULD" and "MUST" (RFC-like) to indicate what is mandatory and what is optional.
We should also consider or check how FLOW3 team is dealing with this (new) challenge, as they are also now maintaining 1.0 while working on 1.1.
#1 Updated by Ernesto Baschny almost 8 years ago
Some idea about the term "no brainer backports", a backport which might need no further review than by the Core Developer that is wanting to merge it:
- the bug fix was already fully reviewed and merged in "master"
- the same fix obviously also applies in the same way in 4.5 and 4.6
because the code has been the same for ages
- no change in system requirements was applied with the fix (i.e. no PHP