Misc #20432: Proposal for workflow changes related to teeny releases

• Status: Open
• Assignee: -

[ufuk (Ufuk Kayserilioglu)]

Aim

• The cadence of CRuby stable releases is very important for how the project is perceived. Users of CRuby want to get more frequent releases with bug and security fixes, so that they feel confident that their projects and businesses continue running smoothly and safely.
• More frequent releases make the community see that the CRuby project is active and thriving. It also allows people to keep upgrading to the latest versions of Ruby with newer features and better security.
• The current cadence of teeny releases are causing concerns in the community, and there have been multiple examples of late releases in 3.0 series, 3.1 and 3.2 series and now 3.3 series. This is creating confusion and doubt in our community and making the community to ask for a change in bug fix release process.
• We all agree that release management is difficult and branch maintainers have a hard job. If we can be making their jobs a little bit easier, they will have more time and opportunities to make more frequent releases.
• This proposal aims to improve some of the workflows around stable branch release management so that branch maintainers have the opportunity to make more frequent bug fix and security releases, thus, addressing some of the concerns from the community.

Proposal(s)

1. A lot of the time of a release manager seems to be spent doing backports to the corresponding stable branch. The current workflow asks bug reports to populate the fields for which stable versions need the fix backported to, and release managers are responsible for keeping up with this list and creating backport commits on stable branches.

   This process is fragile, since the release managers are usually the people with the least amount of context on the particulars of a bug-fix and have to apply the same changes to a different branch and resolve any potential conflicts. This is a task best done by people who already have the most amount of context on the change: the original bugfix author.

   As a result, my suggestion is to make it mandatory for any change that needs to be backported to have backport PRs opened (or corresponding backport patches attached to the Redmine tickets) by the author for the relevant stable branches. That way the authors of changes will be responsible for making sure that the tests pass and the changes apply cleanly on older branches, allowing branch maintainers to come in and merge the PRs, freeing up their time and focus. Since backport PRs will be opened by authors of changes, but only merged by branch maintainers, this will still allow maintainers to control what goes into stable branches.

2. It also seems like branch maintainers are trying to synchronize releases across different Ruby versions, which is causing delays in getting teeny releases out of the door. In my opinion, each stable branch should be responsible for its own teeny releases and there should be no need to synchronize the cadence between different Ruby versions. This will mean less time waiting for other branch maintainers who might be busy with other life priorities, unblocking branch maintainers to be able to do teeny releases whenever it is convenient.

3. Finally, it is my observation that branch maintainers usually make teeny releases whenever there is a security incident that needs to be addressed. A security fix is most definitely a good reason to make a teeny release, but a teeny release should not wait for a security concern to be addressed. There are many other important bug fixes constantly being backported (or needing backports) such as fixes for crashes, fixes for memory retention/leaks or fixes for other behaviour regressions. It is important for end-users to have those addressed as timely as possible, so I would suggest that branch maintainers aim to make about 6-7 teeny releases every year (some of which will be security releases) in order to deliver value to end-users continuously.

Conclusions

Continuous integration and continuous delivery are one of the greatest changes that have happened in the software engineering sector in the recent decades. They allow us to shorten the time of delivery of new features to end-users and reduce the amount of work-in-progress that is waiting to come into the world, thus reducing waste.

By adopting some of the workflow changes that I have suggested above, and maybe other changes that I might have missed, the CRuby core team has an opportunity to make a positive impact on all the users of the Ruby language and to increase the quality perception of the project as a result.

For that reason, I hope my proposals are considered and implemented by the Core team. Thanks for your consideration.

[ufuk (Ufuk Kayserilioglu)]

• Description updated (diff)

[hsbt (Hiroshi SHIBATA)]

• Related to Misc #20422: Bugfix release process added

[masterleep2 (Bill Lipa)]

I think it would be helpful for communications and expectation setting if there was a regular release cadence. Personally I'd be quite happy with quarterly releases, and I only really care about the latest stable.

The main one I'd like to get my hands on in a more predictable way is the first 3.x.1 release that has the most severe detected bugs in .0 worked out.

[jrochkind (jonathan rochkind)]

Thank you for looking into this!

I saw the minutes of the discussion at https://github.com/ruby/dev-meeting-log/blob/master/2024/DevMeeting-2024-04-17.md#misc-20422-bugfix-release-processhsbt--misc-20432-proposal-for-workflow-changes-related-to-teeny-releases-ufuk

I would like to clarify that it is not necessarily a general increase in releases to 6 per year or one every ~2 months that many of us want.

It is rather specifically focused on the .1 release. x.y.0 releasees are historically especially likely to contain serious bugs -- for the simple reason that .0 releases contain bigger changes! The concern/challenge many of us have is that .0 releases have often had memory leaks or other bugs that keep people from using them. These bugs are often fixed soon after the .0 release, but these fixes then often wait on the branch many months for a .1 release -- historically, they generally wait until there happens to be a security patch to release. This could be even longer than we have experienced so far! When many people would like to start using the new Christmas ruby release sooner, if a release were available with the known severe bugs fixed.

To address this concern really specifically requires .1 releases to happen sooner after .0 releases. Or perhaps generally, releases to happen sooner when "serious" bugs already have patches that are waiting for a release -- but historically this has been noticed as an issue especially on .1 releases. It does not necessarily require 6 "tiny" releases a year though.