[REL] Preserve a/b suffixes in tag_regex

[rwgk]

In connection with PR #1606 I looked into how we could do test-run releases, to validate our tooling.

Main pain-point: our current tag_regex strips a/b/rc suffixes, so even tags like 1.2.3a1 collapse to 1.2.3. That makes it hard to do mainstream release test-runs.

IIRC @leofang explained that we need to strip rc, but could we not strip a/b? -- That's this PR.

Assuming #1606 is merged, do we actually still need the rc stripping, or could we go fully mainstream?

[copy-pr-bot]

Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[leofang]

I don't remember I've asked for stripping rc...? In our (now outdated) release checklist, we still have one item which is to tag rc for QA to test. IIRC @mdboom touched the setuptools-scm section, maybe you guys can help me recall the context... 🙂

[mdboom]

I don't remember I've asked for stripping rc...? In our (now outdated) release checklist, we still have one item which is to tag rc for QA to test. IIRC @mdboom touched the setuptools-scm section, maybe you guys can help me recall the context... 🙂

The context is that when we tag a release candidate, and that release candidate is shared with QA and passes cleanly, we want to release /exactly/ the same wheel as the final release. The existing version regex here makes it so the tag 1.2.3rc1 maps to the version 1.2.3 and would produce exactly the same wheel as the tag 1.2.3. I'm not strongly in favor of that approach, since it's a bit magical. I personally think it's fine to make a 1.2.3rc1 wheel and then re-build a 1.2.3 from the same git commit (which would not have the same wheel checksum as the release candidate, but would be built from the same source).

I think the risk this is trying to avoid is that the build infra or requirements change underneath us between the rc and the final, but I see that as a separate problem to solve (making sure versions of everything in our containers are locked down etc.) that seems generally well in hand already.

[rwgk]

I personally think it's fine to make a 1.2.3rc1 wheel and then re-build a 1.2.3 from the same git commit (which would not have the same wheel checksum as the release candidate, but would be built from the same source).

I agree with that.

I think the risk this is trying to avoid is that the build infra or requirements change underneath us between the rc and the final

I believe this will happen, but it seems super unlikely that that will invalidate the QA testing.

[leofang]

Thanks for reminder. I recall the broader context now. Though I am still not sure if I was being very precise up to the "stripping rc" level. Anyway...

• We start drifting away from the old QA process, so it is less likely that an rc build would coincide with the official build that we need to worry about stripping. We might not even be tagging rc going forward.
• That said, before we completely rule out the need of tagging rc and ensure bitwise-reproducibility (coming from the C library background we care this a lot; internally this is also a strong assumption that other teams rely on) in our build setup (which does not rely on tools pre-installed in a container that we maintain) I am not comfortable waiving the said risk.

So, this PR looks good to me.

[rwgk]

/ok to test

[github-actions]

Doc Preview CI
Preview removed because the pull request was closed or merged.