[Process Proposal] One last bug fix (patch) release when ending bug fix support

rubyonrails-core
1

Bug fixes was merged to 6-1-stable after the release of 6.1.4 on 24th June 2021 but before the release of 7.0.0 on 15th December 2021, fall in a sort of awkward middle ground where the 6.1.Z series was still receiving bug fix releases but no further release in the series was made before the maintenance level was reduced to cover security issues only.

Under the current maintenance policy it’s not clear if we should ever expect these bug fixes to be included in a new 6.1.5 bug fix release once there “enough” bug fixes to justify it, or if this is not likely to ever happen - so it would be good to clarify things.

It seems like there are basically 3 options:

  1. No further bug fix releases. Have a general policy that no further bug fix releases for a series will be released after the end of bug fix support, and that the X-Y-stable branch is the way to go (effectively meaning that, with the benefit of hindsight, we could say that the 6.1.Z series stopped receiving bug fix releases after 24th June 2021)
  2. One last release as support ends. Have a process of doing one last bug fix release at (or very shortly after) the time that bug fix support ends, so all bug fixes that were merged up to this point get released and any that get merged after support won’t likely get released (ie: hypothetically releasing a 6.1.5 as the last bug fix version at the same time a 7.0.0 on 15th December 2021). This release acts as the marker after which X-Y-stable is the only way to get bug fixes.
  3. One last release after support ends. Do one last bug fix release whenever there are enough bug fixes sometime after the end of bug fix support (ie: sometime after 15th December 2021 in the example), using whatever the usual heuristic of when there are “enough” bug fixes for justify a bug fix release. This release acts as the marker after which X-Y-stable is the only way to get bug fixes.

To me option (2) seems like the best approach: all bug fixes merged while a series is listed in the “Bug Fixes” section of the maintenance policy get released, after which maintainers can be free of the expectation of further bug fixes.

However I appreciate that option (1) represents the least work, and may already be an undocumented process.

I’m happy to submit a PR to try to document this better once there is some consensus on the best approach.

cc @rafaelfranca - I think your interpretation of the existing policy/process counts for something here! :slight_smile:

(For context, running into this bug was the trigger for this chain of thought, but a number of other bug fixes fall into this gap: Performance regression in CollectionAssocation#build by ghiculescu · Pull Request #42524 · rails/rails · GitHub)

2

What we usually do is (3). (2) puts a lot of strain in the release manager since we would have to release two version of Rails and that is not as easy. A last release for 6.1 is still planned.

3