version: base master nightlies on next unreleased codename (3009.0~nbN) - #70200
Open
dwoz wants to merge 4 commits into
Open
version: base master nightlies on next unreleased codename (3009.0~nbN)#70200dwoz wants to merge 4 commits into
dwoz wants to merge 4 commits into
Conversation
Master nightlies were producing versions like ``3008.2+697.g621251a737``
because ``git describe --match "v3008.*"`` (constraint inherited from a
3007.x forward-merge) hijacked the detected version to Argon's line even
though master is developing toward Potassium. That mis-labels the code,
and once 3008.3 releases, the master nightly RPM/DEB sort *below* it —
so consumers of a nightly mirror wouldn't auto-move to a real stable
3008.3 fix.
Fix master's ``salt/version.py`` in two related places:
1. Swap the ``--match`` constraint from ``v3008.*`` to ``v3009.*``. No
``v3009.*`` tag exists yet, so describe falls through to just the raw
SHA on this branch.
2. Extend the existing SHA-only handler to lift the baseline to
``SaltVersionsInfo.next_release()`` (Potassium/3009 on master) using
``git rev-list --count v3008.0..HEAD`` for the dev-cycle commit
count. Emits a ``pre_type="nb"`` (nightly build) version like
``3009.0nb1292+1292.g621251a737``. PEP 440 sort:
3008.2 < 3008.99 < 3009.0.dev* < 3009.0nb1 < 3009.0nb1292
< 3009.0a1 < 3009.0rc1 < 3009.0
Also guard the module-level ``SaltVersionsInfo._current_release``
override at file bottom against pre-release versions — a pre_release
codename reflects the *next* codename, not the last released one, and
would corrupt ``SaltVersionsInfo.current_release()`` for callers that
expect "last released codename".
In ``tools/changelog.py``, add ``_to_distro_version()`` and use it in
both ``update_rpm`` (extending the pre-existing ``rc`` -> ``~rc``
translation to also cover ``a``/``b``/``nb``) and ``update_deb`` (which
previously had no translation at all). rpmvercmp and dpkg --compare both
treat an extra alphanumeric segment as *greater* than nothing
(``3009.0nb1292`` > ``3009.0``); the ``~`` form sorts *less than
nothing* (``3009.0~nb1292`` < ``3009.0``) — required so nightlies sort
below the eventual final release.
Verified with rpm.labelCompare and dpkg --compare-versions:
3008.2 < 3009.0~nb1292
3009.0~nb1292 < 3009.0~nb1293
3009.0~nb1292 < 3009.0~rc1
3009.0~rc1 < 3009.0
3008.99 < 3009.0~nb1
3009.0~nb1292 < 3009.0
Maintenance branches (3006.x, 3007.x, 3008.x) are unaffected: they keep
their own hardcoded ``--match v<major>.*`` (rebased at branch cut).
twangboy
previously approved these changes
Sep 1, 2026
….Version The Prepare Workflow Run step calls `tools pkg set-salt-version`, which constructs a `tools.utils.Version` (subclass of `packaging.version.Version`) from the discovered Salt version. With this PR now emitting nightly builds as `3009.0nb<N>+<N>.g<sha>`, that constructor raises `InvalidVersion` because PEP 440 has no `nb` pre-release marker, aborting the whole CI matrix at ~1m20s in Prepare Workflow (before any job dispatches). Override `tools.utils.Version.__init__` to rewrite an `nb<N>` pre-release segment to `.dev<N>` before delegating to `packaging.version.Version`. Only the public-version segment (before `+`) is touched; the local-version identifier is left verbatim so a git SHA containing `nb` (e.g. `+1295.gnb12345`) cannot false-match. The translation is intentionally lossy in one direction (only used for comparison / major-minor extraction inside `tools/`); the version string persisted to `salt/_version.txt` and rendered in RPM/DEB names is still the literal `nb` form (translated to `~nb` by `tools/changelog.py`). Semantically, `.dev` is PEP 440's development pre-release marker -- sorts below the corresponding final release, `is_prerelease=True`, `is_devrelease=True` -- which is exactly what a nightly build is.
``SaltStackVersion.__str__`` previously rendered the ``nb`` pre-release
marker verbatim (``3009.0nb1296+1296.g095fa65699``). PEP 440 does not
recognise ``nb``, so ``setuptools``' ``egg_info`` (which validates the
project version via ``packaging.version.Version``) rejected the string
and the entire ``Build Source Tarball`` step of the nightly packaging
pipeline failed, cascading to all downstream builders (14 jobs across
Linux/macOS/Windows onedir + RPM/DEB packages).
The tools-side ``Version`` shim added earlier in this PR normalised
``nb`` -> ``.dev`` only for the CI ``set-salt-version`` step's own
comparisons; setuptools' internal ``packaging.version.Version`` call
was never routed through it.
Fix the emission at the source:
* ``SaltStackVersion.__str__`` now renders ``pre_type == "nb"`` as
``.dev<N>`` (PEP 440's development-release marker, semantically
identical to Salt's ``nb``).
* ``git_describe_regex`` accepts both ``nb`` (legacy) and ``.dev`` (PEP
440) as ``pre_type``; the constructor normalises ``.dev`` back to the
canonical internal ``nb`` so comparisons and lookups round-trip.
* ``bugfix``/``mbugfix`` regex groups now require at least one digit
(was ``{0,2}``) so an optional ``.dev`` marker isn't greedily eaten
as an empty ``bugfix`` capturing the leading dot.
* ``tools/changelog.py`` rewrites ``.dev`` (and the legacy ``nb``) to
``~dev`` / ``~nb`` for RPM/DEB versions so pre-releases still sort
below the unadorned final release under rpmvercmp / dpkg-vercmp.
* ``test_discover_version`` fixtures pin ``next_release() ==
current_release()`` so the legacy SHA-only fallback expectations
aren't clobbered by the master-nightly branch added by this PR.
Verified locally: ``python -m build --sdist`` now clears ``egg_info``
without ``InvalidVersion`` for both ``3009.0.dev1296+1296.g095fa65699``
(new emission) and the legacy ``3009.0nb1296+…`` form (still parseable).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Master nightly builds are producing versions like:
That is wrong — master is developing toward Potassium (3009), not Argon (3008). Two concrete failure modes:
3008.2+697.g...<3008.3, so nightly-repo consumers wouldn't auto-move onto a real stable 3008.3 fix — even though the nightly code is functionally pre-3009 (i.e., way ahead of 3008.3).salt --versions-reportsays 3008; bug triage lands against the wrong branch.Root cause
salt/version.pyrunsgit describe --match "v3008.*". That constraint was correct on 3008.x (it's what #70170 landed there) but got carried through into master — so on master, describe findsv3008.2in ancestor history and producesv3008.2-697-gSHA, which parses back to a 3008-line version.Fix
Two edits, master only.
salt/version.py--matchconstraint tov3009.*. No such tag exists yet, so describe falls through to just the raw SHA on master.noc=-1) to lift the baseline toSaltVersionsInfo.next_release()(Potassium/3009) and count commits since the previous major's first tag (v3008.0..HEAD). Emits apre_type="nb"(nightly build) SaltStackVersion:SaltVersionsInfo._current_releaseoverride at the bottom of the file against pre-release versions — a pre-release codename reflects the next codename, not the last released one, and would corruptSaltVersionsInfo.current_release()for callers that expect "last released codename" semantics.tools/changelog.py_to_distro_version()helper and use it in bothupdate_rpm(extending the pre-existingrc→~rctranslation to also covera/b/nb) andupdate_deb(which had no translation at all).rpmvercmpanddpkg --compare-versionstreat an extra alphanumeric segment as greater than nothing (3009.0nb1292>3009.0); the~form sorts less than nothing (3009.0~nb1292<3009.0) — required so nightlies sort below the eventual final release.+) is rewritten; the local-version identifier stays literal to avoid theain an SHA (e.g.621251a737) false-matching.Verified ordering
Under both
rpm.labelCompareanddpkg --compare-versions:3008.2<3009.0~nb12923009.0~nb1292<3009.0~nb12933009.0~nb1292<3009.0~rc13009.0~rc1<3009.03008.99<3009.0~nb13009.0~nb1292<3009.0Blast radius
Master only. Maintenance branches (3006.x, 3007.x, 3008.x) keep their own hardcoded
--match v<major>.*(rebased at branch cut) and are unaffected.Test plan
python3 salt/version.pyin a master checkout emits3009.0nb1292+1292.g621251a737(was3008.2+697.g621251a737).SaltVersionsInfo.current_release()still returnsArgonafter import (poisoner guard works).SaltVersionsInfo.next_release()still returnsPotassium._to_distro_version()unit tests pass (rc, a, b, nb; stable+local untouched; SHA hex not false-matched).pre-commit run --files salt/version.py tools/changelog.py— clean.salt-3009.0~nb<N>+<N>.g<sha>-*RPM/DEB names on packages.broadcom.com.