In particular, why not tag release/ulmo.2 right now?
Historically, Open edX point releases go out on a 2-month cadence, something like this:
- Dec 9:
release/zebrawood.1 - Feb 9:
release/zebrawood.2 - Apr 9:
release/zebrawood.3
and when the .1 release is delayed, the point releases are delayed too. So in the case of Ulmo, we’d have:
- Jan 18:
release/ulmo.1 - Mar 18:
release/ulmo.2 - May 18:
release/ulmo.3
But here’s the thing, there are three important fixes sitting on the tip of the release/ulmo right now: a critical bugfix for the Catalog MFE, a Django security fix, and critical fix to the openedx image build. We need to get these into a Tutor patch release ASAP, so that Tutor v20 (Ulmo) users can have a secure and functioning platform. But, due to the delay of the ulmo.1 release, we’re still over a month from the planned ulmo.2 tagging date.
When this has happened in past releases, the strategy has been to cherry-pick the critical fixes into the Tutor Dockerfile, and then do a Tutor patch release. For example, in Quince, Tutor had to do a v17.0.5 release to cherry-pick in a privilege escalation fix which merged into the quince branch but missed the quince.3 tag. Yes, we could do this now for the three Ulmo fixes I listed (and that’s what I’ll do tomorrow if this proposal is rejected :).
But, it seems backwards to me that we’re relying on Tutor to cherry-pick in critical fixes rather than doing our own Open edX patch releases. Plus, as a Tutor maintainer, I can vouch that these Dockerfile cherry-picks are a pain in the neck to keep track of, especially across the main and release branches 
My immediate proposal for BTR
Release ulmo.2 now so that we can push these importantfixes out without modifying Tutor’s Dockerfile. We’ll then cut a Tutor patch release which simply updates OPENEDX_COMMON_VERSION from ulmo.1 to ulmo.2.
My long-term proposal for BTR
Stop: tagging .1 , .2, .3 on a strict schedule.
Stop: cherry picking into Tutor’s Dockerfile
Start: the following process…
.1is tagged according to the schedule.2,.3,.4, etc. can be tagged when either of the following are true:- the release manager deems it appropriate to push out fix(es)
- approximately 2 months have gone by since the last point release.
- The final point release goes concurrently with
.1of the next named release, thus ensuring that there are no dangling “unreleased” commits one a named release at the point where it goes out of support. - Every named release will have at least four point release (
.1,.2,.3,.4), but if may have many more if necessary.
Example:
yucca.1goes out on Jun 9 according to the schedule.yucca.2goes out on Jun 19 because a critical bug is found and fixedyucca.3goes out on Aug 19 because 2 months have passedyucca.4goes out on Aug 30 to fix a django security bugyucca.5goes out on Aug 31 to fix another security issueyucca.6goes out on Oct 31 because 2 months have passedyucca.7goes out on Dec 9, which is whenzebrawood.1goes out. Yucca is now unsupported.
Benefits: Fixes are officially released and blessed by the Open edX project rather than relying on Tutor to decide what’s critical enough to patch. Tutor gets simpler–no more patch conflicts between the main and release braches. Critical fixes no longer get “lost” just because they merged after .3 but before the next release was tagged.
Drawbacks: The release manager will need to run the tagging script more often. They need to tag every released repo to do a point release, not just the affected ones. This will be some added work, but I’m happy to help improve the automation if this becomes a point of friction.