Handle major versions and non-rc prereleases #43
Conversation
This commit adds support to the qiskit-bot release automation to handle major version releases and non-rc pre-releases. The major version handling is primarily for building the log command, as we need to get the log from 'n.0.0..n-1.m.0' where m is the most recent non-prerelease. To handle non-rc prereleases the only change is we don't create a new branch for the pre-release. Previously all pre-releases would trigger branch creation (given the appropriate configuration variable). But the desired behavior is to actually only create a stable branch from a release candidate.
There was a problem hiding this comment.
This looks sensible to me. The main question is about whether we need to / ought to handle the last-minor-is-only-deprecations version strategy we were thinking of doing for all Qiskit majors here.
As a minor aside - log messages are typically not supposed to be eagerly formatted, right? It's not going to matter here, because there's no real performance concerns, just a minor note.
qiskit_bot/release_process.py
Outdated
| # If a minor release log between 0.X.0..0.X-1.0 | ||
| elif version_obj.major >= 1 and version_obj.minor == 0: | ||
| tags = git.get_tags(repo) | ||
| previous_major = version_obj.major - 1 | ||
| for tag in tags.splitlines(): | ||
| tag_version = parse(tag) | ||
| if tag_version.is_prerelease: | ||
| continue | ||
| if tag_version.major == previous_major: | ||
| old_version = tag | ||
| break | ||
| else: | ||
| old_version = f"{version_obj.epoch}.{version_obj.minor - 1}.0" |
There was a problem hiding this comment.
The comment at the top here looks like it's now attached to the wrong branch of this if/elif chain now.
Also, this might be a bit tricksy with regard to the Qiskit 0.46 strategy - the changelog we'll actually care about will typically be the penultimate minor, in the "final minor is the deprecation boogaloo" style we were planning to do with our majors, I think? With things as currently written, and how we've been merging up from 0.45 to 0.46, I think the ... comparison is going to end up including the bugfixes from 0.45.1+ in the changelog for 1.0? Not certain about that.
There was a problem hiding this comment.
I had forgotten about the 0.46.0 release when I wrote this logic. If we tag 0.46.0 before we tag 1.0.0rc1 then this will be 1.0.0rc1...0.46.0, while if we tag rc1 before 0.46.0 it will be 1.0.0rc1...0.45.x. At the end of the day I don't think it'll make a huge difference as long as we forward port any bugfixes from stable/0.45 to stable/0.46 it will be basically the same history I think.
Yeah that's a good point. The logging in the tool could probably use a bit of an overhaul as it's also a bit higher priority than it should be in a lot of cases. Like the git activity should probably be debug not info |
This commit adds support to the qiskit-bot release automation to handle major version releases and non-rc pre-releases. The major version handling is primarily for building the log command, as we need to get the log from 'n.0.0..n-1.m.0' where m is the most recent non-prerelease. To handle non-rc prereleases the only change is we don't create a new branch for the pre-release. Previously all pre-releases would trigger branch creation (given the appropriate configuration variable). But the desired behavior is to actually only create a stable branch from a release candidate.