Preserve .dev0 suffixes in cuda.bindings versions

[rwgk]

WIP / TODO

[copy-pr-bot]

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

Contributors can view more details about this message here.

[rwgk]

Do we still need the special handling that strips rcN?

Reviewing the current release workflow suggests that stripping rcN cannot work through that workflow:

1. The release workflow normally finds the successful CI run triggered by the exact requested tag. Supplying a run ID manually changes which artifacts are downloaded, but does not change the version expected from the release tag (workflow).
2. Our custom tag_regex values intentionally omit rcN from the captured version. For example, building from v13.5.0rc1 therefore produces wheels versioned 13.5.0, not 13.5.0rc1.
3. The release tooling independently parses the full version from the requested tag. For v13.5.0rc1, it derives the expected wheel version 13.5.0rc1 (tag parsing, expected-version derivation).
4. Before both the TestPyPI and PyPI uploads, the workflow requires every wheel version to match that tag-derived version exactly (TestPyPI and PyPI validation, exact comparison).

Consequently, a wheel built from v13.5.0rc1 under the current tag_regex would be versioned 13.5.0, while the release validator would require 13.5.0rc1; the release would fail before upload.

The historical motivation appears to have been the ability to test an RC-tagged wheel and later promote that exact wheel as the final release. The current release workflow does not appear to implement that model. I may be missing a separate release or promotion path, so the key question is: do we still have an actual use case that requires stripping rcN?

If not, I propose removing the custom tag_regex from all CUDA Python components and letting setuptools-scm parse the complete tag version normally. This would make the version mapping transparent, avoid silently truncating otherwise unrecognized suffixes, and keep version-policy validation where it belongs: in the release workflow.

[rwgk]

Before I arrived at the question posted in #2919 (comment), I had the considerations below. They will be moot if we go ahead with removing the tag_regex, but I want to capture them here for future reference.

The existing custom regex is doing two jobs at once:

1. It implements a version-mapping policy: preserve aN and bN, but strip rcN.
2. It looks like a defensive allowlist for the tag formats we expect.

As a defense mechanism, however, it is imperfect. The expression is anchored at the beginning but not at the end, so it can silently accept only a prefix of an unexpected tag. For example, an unrecognized suffix can be discarded and the tag reinterpreted as an apparently valid version instead of being rejected. The allowlist also obscures the actual mapping policy and requires us to extend the regex whenever we introduce another legitimate suffix, as this PR does for .dev0.

I therefore have doubts about piggy-backing validation onto the regex when the intended special behavior is simply “strip a terminal rcN.” If we retain that behavior, I think the extraction rule should express it directly and require the complete tag to match. Validation of whether a tag is a supported release version belongs in the release workflow, where it can be explicit, use proper version parsing, and fail clearly. Unexpected tag syntax should be rejected rather than silently truncated into a different version.