version: base master nightlies on next unreleased codename (3009.0~nbN)

[dwoz]

Problem

Master nightly builds are producing versions like:

salt-3008.2+697.g621251a737-0.x86_64.rpm

That is wrong — master is developing toward Potassium (3009), not Argon (3008). Two concrete failure modes:

1. Wrong sort order after 3008.3 releases. rpm/dpkg both compare 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).
2. Version string lies about what code it is. salt --versions-report says 3008; bug triage lands against the wrong branch.

Root cause

salt/version.py runs git 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 finds v3008.2 in ancestor history and produces v3008.2-697-gSHA, which parses back to a 3008-line version.

Fix

Two edits, master only.

salt/version.py

1. Swap the --match constraint to v3009.*. No such tag exists yet, so describe falls through to just the raw SHA on master.
2. Extend the existing SHA-only handler (previously it just recorded the SHA and left noc=-1) to lift the baseline to SaltVersionsInfo.next_release() (Potassium/3009) and count commits since the previous major's first tag (v3008.0..HEAD). Emits a pre_type="nb" (nightly build) SaltStackVersion:

3009.0nb1292+1292.g621251a737

3. Guard the module-level SaltVersionsInfo._current_release override 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 corrupt SaltVersionsInfo.current_release() for callers that expect "last released codename" semantics.

tools/changelog.py

• Add _to_distro_version() helper and use it in both update_rpm (extending the pre-existing rc → ~rc translation to also cover a/b/nb) and update_deb (which had no translation at all).
• Both rpmvercmp and dpkg --compare-versions 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.
• Only the public-version segment (before +) is rewritten; the local-version identifier stays literal to avoid the a in an SHA (e.g. 621251a737) false-matching.

Verified ordering

Under both rpm.labelCompare and dpkg --compare-versions:

a	rel	b
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

Blast 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.py in a master checkout emits 3009.0nb1292+1292.g621251a737 (was 3008.2+697.g621251a737).
• SaltVersionsInfo.current_release() still returns Argon after import (poisoner guard works).
• SaltVersionsInfo.next_release() still returns Potassium.
• _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.
• rpm.labelCompare + dpkg --compare-versions verify the six representative pairs above.
• After merge: mirror to salt-nightlies + fresh master nightly.yml produces salt-3009.0~nb<N>+<N>.g<sha>-* RPM/DEB names on packages.broadcom.com.