overhangio
Suggestion: Early dev releases for named release branches
As a Tutor plugin developer, it's difficult to manage versioning before Tutor makes a PyPI release for a named release cut. We manage several plugins that we are developing against unreleased Tutor / Tutor MFE versions, and cannot release those plugins for testing until Tutor does a release. The plugins also cannot have the correct Tutor required versions until that release is done leading to issues where, for example, the plugin needs to require Tutor 20 in order to test against the Ulmo branch.
As a way to work around this, I'd like to suggest the following:
- When a new release is cut, create the branch for the next release and immediately bump the major version in that branch
- On a cadence (on merge, daily, weekly, etc) tag and create a new dev release (ex:
22.0.0dev1) without changing the actual version in__about__.py.
This will allow plugin developers to target >=22 immediately and enable finer grained dependency control during development so we can target something like >22.0.0dev55 when breaking changes land in the branch. It should also simplify setting up testing sandboxes against named releases going forward since we should be able to release plugin versions that target the right things instead of having to install from branches until the main Tutor packages are bumped.
Interesting idea. Tutor's official plugins could benefit from this as well. We make release branches anyway, but we typically do that near the cutoff. One downside is that we would have to maintain that branch (periodically merge or rebase from main) for 6 months. There would also be the added confusion of target branches in PRs—i.e., release, main, and {next_release}.
Alternatively, we could explore separating versions on the main and release branches. The main branch would always have the next major version, which would address your need to target future versions immediately after a release cut.
