Add pythonrelease and pythonrelease_info grains

[xhon-pelushi]

What does this PR do?

Adds pythonrelease and pythonrelease_info grains.

What issues does this PR fix or reference?

Fixes #59594

Background

pythonversion is a list rather than a dotted string:

pythonversion:
    - 3
    - 11
    - 0
    - final
    - 0

which breaks the <foo>release / <foo>release_info convention the other version grains follow (osrelease is 7.9.2009 with osrelease_info carrying the tuple; likewise kernelrelease).

The issue suggested adding pythonrelease / pythonrelease_info and deprecating pythonversion at some documented future point. This PR does only the additive half — it deliberately does not touch or deprecate pythonversion, so it carries no backwards-compatibility risk. The deprecation is a separate decision for the maintainers.

Result

pythonversion:      [3, 12, 3, 'final', 0]   # unchanged
pythonrelease:      '3.12.3'
pythonrelease_info: [3, 12, 3, 'final', 0]

pythonrelease uses platform.python_version(), which is defined as major.minor.micro and so matches the shape of osrelease.

Tests written?

Yes — added test_pythonrelease to tests/pytests/unit/grains/test_core.py, asserting the dotted form matches both platform.python_version() and major.minor.micro, that pythonrelease_info matches sys.version_info, and that it stays in sync with the pre-existing pythonversion grain.

Verified locally:

• Both test_pythonversion (pre-existing, confirming the old grain is untouched) and the new test_pythonrelease pass against the real salt.grains.core module.
• Checked the two other tests that reference this grain — tests/pytests/integration/modules/grains/test_module.py and tests/pytests/pkg/integration/test_salt_grains.py — both assert membership (assert grain in ret.data) rather than an exact grain set, so adding grains does not affect them.
• black==24.2.0 (the version pinned in .pre-commit-config.yaml) reports both changed files unchanged.

I was not able to run the full tests/pytests/unit/grains/test_core.py suite locally — the salt-factories conftest setup didn't complete in this environment — so CI is the real check on the rest of that file.

Commits signed with GPG?

No

[twangboy]

We'll run these test once the nightlies master branch tests are green. Otherwise they have no hope of passing. Or you could rebase this on the 3008.x branch.

[xhon-pelushi]

Thanks @twangboy — the master nightlies still aren't green, so I've taken the second option: this is now rebased onto 3008.x and the PR base has been retargeted to 3008.x.

For reference, every Nightly (branch: master) run has failed for the last 10 days, including the most recent one against the current master tip (8c502c0b):

Date (UTC)	master	3008.x
2026-08-20	failure	in progress
2026-08-19	failure	success
2026-08-18	failure	success
2026-08-17	failure	success
2026-08-16	failure	success
2026-08-15	failure	success

The rebase was clean — this is a single, purely additive commit and pythonversion() is identical on both branches, so it applied with no conflicts and the diff is unchanged (3 files, +39/-1). platform and sys were already imported in both salt/grains/core.py and tests/pytests/unit/grains/test_core.py on 3008.x, so no new imports were needed.

Happy to move it back to master if you'd rather wait for the nightlies there.

[xhon-pelushi]

Rebased onto current 3008.x (191a6df6) to get CI off a stale failure. The change itself is
untouched — same three files, same +39 −1, and the rebase was clean.

To explain why this was still red: the failing run here is from 20 August, and the 15 failures in
it were all Build Salt Onedir / Build Source Packages / Build Onedir Packages jobs. None of
them reached the grain code. They died building the pyzmq wheel:

[107/109] Generating _src/_zmq.c
FAILED: [code=1] _src/_zmq.c
  _zmq.py:357:8: 'hint' redeclared
  _zmq.py:1112:12: 'c_addr' redeclared
ninja: build stopped: subcommand failed.
ERROR: Failed building wheel for pyzmq

— a Cython-version incompatibility in the dependency build, not anything in this PR.

That is fixed on 3008.x now: in the most recent branch CI run there, all 20 Build* jobs are
green and the only failures are Test Salt integration jobs. This PR just never re-ran, and
GitHub had it marked BEHIND. The rebase should give it a clean set of build jobs.

One thing worth your call while it re-runs. The unit test I added asserts

assert ret["pythonrelease"] == "{}.{}.{}".format(*sys.version_info[:3])

which holds for final releases but would fail if the onedir were ever built against a pre-release
Python, since platform.python_version() returns e.g. 3.14.0rc1 while that format string gives
3.14.0. I have deliberately not changed it here, so the approved diff stays byte-identical — but
say the word and I will drop that one assertion (the two either side of it already cover the
grain's contract).

[xhon-pelushi]

Correcting myself on one point above: I said the rebase should give this a clean set of build jobs.
It will not on its own — no workflow has started.

Half an hour after the push there are zero Actions runs for 7d3c0d35, on this repo or on my fork.
The only check present is the WIP marketplace app. So this needs someone to hit Approve and
run workflows — I assume the force-push reset whatever approval the 20 August run had.

Everything else in my previous comment stands: the rebase is clean, the diff is unchanged at
+39 −1, and the pyzmq build failure that produced the 15 red jobs is gone from 3008.x.

Sorry for the extra notification — better than leaving you to wonder why nothing was running.