Permalink
Reply
This year I took over the release process from Iain, not because I am so qualified as a 'DevOps Engineer' (I actually had to look that term up) but out of necessity. Therefore I planned to just 'cruise' for the time being and follow the existing process without touching anything. However, the current release process causes so much friction that I want to change it sooner rather than later. For the Symmetry Autumn of Code (SAoC), there is an idea for a project to streamline the release process. This is mostly about the infrastructure for building releases and uploading the downloads to the server. What I want to discuss now is the release schedule, branching strategy, and contributor experience.
Issues with the current process
- The distinction between the master/stable branch is vague and time-dependent. Some say stable is for 'critical' bug fixes, other say it's for 'safe' bug fixes, but DMD's semantic analysis order is so fragile that even 'safe' bug fixes have caused projects to break after an update from release candidate to actual release version.
- Pull Requests that target the default master branch often contain discussions "please rebase to stable", "won't do because X", "will do because Y", "okay I tried but now commits are all messed up", etc. This wastes the contributor's and reviewer's time.
- Stable constantly needs to be manually merged into master to prevent conflicts and keep nightly up to date
- Patch releases are not possible after master gets merged into stable. So once I build a beta for 2.112.0, I can't build 2.111.1 anymore.
- Relatedly, people have requested LTS (Long Term Stable) releases which don't fit into our current branch structure
- The frequency of beta, release candidate, and patch versions is high, adding to the workload of the release manager while there are still so many manual steps in the process. Following the existing cadence I'd build 4 releases in a span of 4 weeks. Many of these releases only differ by a handful of commits, and while there is no urgent problem with server storage, the gigabytes are slowly piling up.
- To add to that, only a small percentage of people actually seem to actually test beta/rc versions. Most regression bug reports come in after a release has been pushed to package managers.
- Releases are tagged purely based on time, even when we're in the middle of a series of incremental pull requests, causing half-finished work to unintentionally appear in a release sometimes.
Proposal
- All contributions go into the master branch.
- Every 3 months a feature freeze for a minor version is created in a branch called 2.XXX
- Maintainers can add a 'backport-to-2.XXX' label to a PR, triggering a GitHub Action to merge it into that version branch (unless there are merge conflicts, then manual action is required)
- 'stable' points to the latest minor release branch for backwards compatibility
- Nightly builds continue as always, being built from master
- Consider making 1/4 releases (or 1 per year) Long Term Stable (LTS)
- Backports to LTS / feature branches are done on an as-needed basis. Patch releases aren't created based on whatever bugs happened to be fixed the month after the first minor release, but because critical bugs/regressions popped up that prevented (industry) users from getting work done.
- Try using GitHub milestones to coordinate features with release versions
Maintainers still need to decide what master commits go into what version branch, and merge conflicts can still happen, but at least this should remove most accidental complexity. We no longer need to pester authors of Pull Requests about which branch to target, and there's much more clarity on what's happening: You don't need to cross-reference the release schedule with the PR's merge timing to figure out where it's ending up.
Feedback
If I missed any (technical) considerations, please let me know. This is just my proposal based on current observations, it can be adjusted as we go. For example, the frequency of releases can be increased if there's demand and the process gets streamlined.
Current status
I won't implement this before DConf, I'm currently focussing on building 2.112.0. I need to update the Visual Studio installation on the Windows VM to make that work. I'm also looking to add a certificate to the MacOS releases (courtesy of @LunaTheFoxgirl, thanks!), which also requires changing what happens inside the MacOS VM. Like I said, this is all new to me, so if anyone wants to help out that would be appreciated.
