This note is about the release sequence leading up to the next production release. I’ll (try to) write another note about beyond the next production release later today.
Our next production release is nominally named 4.20 and scheduled for before July 10th.
Our normal sequence is then a test release 4.19.7 around now that’s the last from the HEAD of master. I’d like to build this next weekend, ideally Saturday May 30.
After that, the criteria for including changes great stricter and stricter.
A) Bug fixes and _small_ changes will be included in a 4.19.8 test release around June 15
B) After that, only very specific fixes for identified regressions will be included; if there are any, additional test releases will be made as needed.
It’s important that merging the changes in (A) and (B) do not bring in other things. That’s quite trivial to do: When you start work on of those
git checkout v4.19.7
git checkout -b branchForMyFeature
so that you’re making changes based on 4.19.7, not on top of changes that took place after that. (Earlier, like v4.19.6 or master before v.4.19.7 is cut, is also fine) That’s all it takes.
But essentially every time, we get a contribution that’s not like this, because it comes from master later and pulls in other changes. What to do? Last time I came up with a branching scheme that would let people continue to work off master. It too required people to think about where they branched their work, and wasn’t really a success.
So this time, I propose:
i) Development will continue via master as usual so it doesn’t get too far behind
ii) Changes to be included in v4.20 will be merged iff they’re branched from v4.19.7 or before.
iii) Changes for 4.20 branched too late will have to be moved (via various git operations) to a from-v4.19.7 branch before being merged.