During the 5.8 release cycle, a Release Lead The community member ultimately responsible for the Release. and Release Deputy was named for all 5.7.x releases in a trial run. The experiment was an attempt to address several pain points that made executing minor releases needlessly difficult. Each of the pain points of the minor release cycle were expanded in detail in the original post.
For the 5.7.x releases, @peterwilsoncc and @audrasjb were named as Release Lead and Release Deputy respectively. In the months between the 5.7 and 5.8 releases, they successfully planned and released 2 minor 5.7.x versions with an average of 4.5 weeks between each. The gap between the final minor release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. (5.7.2) and 5.8 was 9.7 weeks.
Feedback
In an effort to evaluate how this process went, they were asked for some answers to a handful of questions. Here is some collected feedback from @peterwilsoncc on how the process went.
What went well?
Generally I thought the experiment was successful and it was good to be able to concentrate (and only be expected to concentrate) on the minor releases rather than try to track both major and minor. More specifically:
- Getting a few more people in the AEST timezone involved than usual helped with coordination.
- Starting early my time for releases was good for the .1 version as it went longer than expected.
- Probably should have asked for author rather than contributor permission on w.org/news so I could actually publish the posts I prepared.
- Having scripts prepped a day in advance was great at reducing stress and allowed for dry-runs (excluding commit).
What went poorly?
- Night owls or not, I don’t think it was great having me in APAC and @audrasjb in EU working as team leads, everything that was good about release times for me was exactly the reverse for @audrasjb (and @desrosj but to a lesser extent).
- Better prep on the .1 release could have shortened the time for committing and moving on to the release party.
- Needed to pull in a couple of people on the release day for the .1 release.
- Finding someone with mission control access is not easy (especially in timezone). The list of those with permissions is really out of date, and some probably don’t need release permission any more.
- I didn’t delegate some of the admin (and super admin) stuff well and ended up doing a fair bit at the last minute as a result (on me for not asking).
What did you learn?
- How to release Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ packages, although doing so on my first production commits to the repository was a little brave.
- Depending on the number of security backports, and how far back they need to go, release day for a minor can be busier than a major.
- Process page in the handbook is quite out of date: updated a few steps after each of the two releases.
What support did you receive?
A lot.
- @gziolo and @isabel_brison helped a great deal with getting the Gutenberg release process down, especially @gziolo by updating the undocumented steps as I asked questions.
- @audrasjb, @desrosj and @whyisjake with release processes, both in advance and on the day.
- Code review of shell scripts to attempt to speed up the process.
- @dd32 with release day stuff, including catching quite a few things I was unaware of on the day.
What support could you have used?
Needed a lot more support from editor team with some planning tasks. The team was consumed with 5.8 and Full Site Editing, so they did not have much time to spare.
What were some responsibilities or tasks you had to take care of that you did not anticipate?
- Expected I’d need to prep some release day scripts, but didn’t realize how many until I started doing them. Again, probably would have been helped by better delegation
- Didn’t realize I’d need to do NPM releases at the start but figured it out well before the actual release
Anything else you feel is worth sharing?
Generally I think it went well and was successful.
Continuing the trial in 5.8.x releases
Because the experiment was generally successful, it will be repeated in 5.8.x releases. To reiterate the ideal criteria that was listed in the original proposal, the two contributors serving as release lead and release deputy will be responsible for:
- Publishing timelines and plans for each minor release.
- Executing these plans through release day.
- Coordinating with the Security Team lead to improve the flow of fixes from the team to users.
- Assembling and requesting help from other volunteers for each release as deemed necessary (docs, test, specific focus areas, etc.).
Ideally, one of these two contributors has a technical background (with the abilities to identify, confirm, test, and approve bug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes and changes), and the other has a project manager or coordinator background (with the abilities to create release timelines, coordinate contributors, and help unblock efforts).
One additional (potentially optional) criteria would be that either the lead or deputy be a part of the previous major release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.’s squad, or be very familiar with the changes that were introduced in that major release. This would further increase the speed at which the minor releases are able to fix related bugs, as they are already “up to speed” on the changes.
In recent years, the gap between major releases has been, on average, 3 to 5 months. If necessary, contributors can tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) in and out of the role should circumstances change and it becomes necessary.
If you’re interested in volunteering as a Release Lead or Release Deputy for the 5.8.x releases, please comment below!
Props @peterwilsoncc and @audrasjb for their great work during the 5.7.1 and 5.7.2 releases, and @chanthaboune for pre-publish review.
#5-7, #5-8
