Salt: three release branches in about two hours, and packages on a vendor URL

Three branches shipped within twenty-five minutes of each other

Look at the timestamps on the three most recent releases. v3008.5 was published at 22:23:46 on 2026-10-26. v3006.30 followed at 00:19:04 on 2026-10-27, and v3007.17 at 00:26:30. About two hours separate the first and the last.

That pattern is the versioning model. The 3006, 3007 and 3008 lines are all maintained in parallel, and patch releases for each of them shipped within about two hours. The trailing numbers are the patch counts, and v3006 is already at .30 while v3008 is at .5, which tells you the older line has absorbed far more fixes over a comparable period.

The consequence for an adopter is that you are choosing a branch, not picking a version. There is no single upgrade to wait for. When a security fix lands, it lands on all three lines at once, and you have to decide how far to move each one you run. Running a mix of branches across a fleet is a normal state rather than a mistake, which is unusual for infrastructure tooling and worth internalising before you design a rollout.

The last push to the default branch master was on 2026-11-02. Nothing here suggests the project is winding down; it suggests an unusually well funded maintenance cadence, with three streams to watch instead of one.

Official packages are served from packages.broadcom.com, not from a project domain

The download section points at three Artifactory repositories, and they are not on a saltproject.io or GitHub address:

packages.broadcom.com/artifactory/saltproject-rpm
packages.broadcom.com/artifactory/saltproject-deb
packages.broadcom.com/artifactory/saltproject-generic

The RPM and DEB repositories are where the Linux packages are officially stored and distributed. The generic repository is where the Windows, macOS and other non-rpm, non-deb packages live. Salt is stated to be tested and packaged to run on CentOS, Debian, RHEL, Ubuntu, macOS and Windows.

There is a coherence here. The documentation on docs.saltproject.io explains how to install, and the packages themselves come from Broadcom's artifact repository. For a system administrator that is a normal arrangement: vendor-hosted repositories for vendor-maintained packages, documentation that tells you which URL to configure.

It is also a dependency on a single commercial domain, and worth naming as such. If your reason for choosing Salt was avoiding vendor lock-in, an Artifactory instance at a single vendor URL deserves a second look before you commit a fleet to it. The project is Apache-2.0 and you can always build from source, since the repository carries pyproject.toml, setup.py and a pkg/ directory. But the path of least resistance for a binary upgrade runs through that one host.

Mirroring the repository internally, or planning to build from source, converts this from a risk into a decision.

salt-cloud -p takes only the VM name, and attributes belong in the profile

There is one usage note in this README that is not marketing at all, and it is the sort of thing that saves an afternoon:

> When using ``salt-cloud -p`` with a profile, pass only the VM name on the command line. Specify VM attributes such as memory, cpu and vcpu in the profile configuration, not as command-line arguments.

That is a rule about argument placement. You invoke salt-cloud with the -p flag pointing at a profile, and the only thing that belongs after it is the VM's name. The sizing lives in the profile file.

The pattern generalises across Salt. The project describes itself as event-driven, with state and execution modules that describe desired configuration, so configuration belongs in the state and in the profile rather than on the command line where it cannot be reviewed, reused or diffed. A fleet provisioned from command-line arguments is a fleet whose configuration lives in someone's shell history.

If you are evaluating Salt, this note is a fair proxy for the rest of the documentation. It is short, specific, and it tells you where to put things without explaining the internals first.

setup.py imports distutils and keeps a urllib2 fallback, which is why the build has its own backend

pyproject.toml does not use setuptools as its build backend. It declares an in-tree one:

[build-system]
build-backend = "salt_build_backend"
backend-path = ["tools/pkg"]

A backend path pointing into the repository means the build imports a module shipped alongside the source rather than one installed from an index. Now read setup.py, which sits next to it, and the reason becomes visible.

The setup script imports distutils directly, including distutils.errors for DistutilsArgError, distutils.command.build, distutils.command.clean, distutils.command.install_lib and distutils.log. It then runs the classic Python 2 compatibility dance:

try:
    from urllib2 import urlopen
except ImportError:
    from urllib.request import urlopen

It also probes for optional capabilities rather than requiring them, setting a flag when wheel's bdist_wheel is available and another when zmq imports, and it reads SOURCE_DATE_EPOCH for a reproducible build date, falling back to the current time when that variable is unset.

So the legacy setup path relies on a module newer Python versions no longer ship in the standard library, and carries a fallback for an import that was removed years ago. That is the context in which a custom in-tree backend makes sense. The practical consequence is for anyone packaging Salt downstream: an in-tree backend has to be present in the sdist and correct, and the build requirements list includes setuptools, wheel, looseversion, packaging and importlib-metadata. If you are mirroring, building or vendoring Salt, that is the part to test.

requires-python has no ceiling while the classifiers stop at Python 3.10

The project metadata sets a floor and no upper bound:

requires-python = ">=3.8"

The classifiers beside it declare Programming Language Python 3.8, 3.9 and 3.10. Nothing above 3.10.

Read together, they say something the README does not. pip will resolve and install this package on any Python 3.8 or newer, including versions released well after the newest declared classifier, because that is what the constraint says. The classifiers are the narrower claim, and they are what maintainers use to record what they actually test against.

That gap has a concrete failure mode. On a newer interpreter the install succeeds, and you find out whether it works by running it. For an automation tool that touches production infrastructure, that is the wrong order of operations.

The resolution is dull and worth stating: treat the classifier list as the supported set and the requires-python line as a lower bound on what the installer will permit. If you run a Python newer than 3.10, you are outside the declared support surface and you are the one who will find the break.

One related detail is a reminder of the project's age. The authors field lists a single name, Thomas S Hatch, while the README describes a community of more than 3,000 contributors. Package metadata of this vintage does not get modernised, so read it for the constraints it encodes rather than for the people it credits.

black and isort both skip salt/ext and templates, so those trees are outside the format contract

The formatting configuration names the same two exclusions twice:

[tool.black]
exclude= """
/(
    salt/ext
  | templates
)/
"""

and, in the isort settings, skip set to "salt/ext,templates". isort is configured with a line length of 88 and set to a vertical hanging indent with trailing commas, parentheses and comments kept on their own line. pytest is the one package marked as known third-party.

The exclusions are the interesting part. Neither is formatted by the project's own tools, deliberately, because you do not want a formatter rewriting vendored code or breaking a template whose whitespace matters.

The consequence is narrow but real: a diff touching salt/ext or templates is unformatted by construction, so reviewers cannot rely on the formatters having normalised it. And since isort skips the same paths, import order in those trees is maintained by hand.

The top level reinforces how much tooling surrounds the code. There is .pylintrc, .pre-commit-config.yaml, .bandit for security linting, .coveragerc and .codecov.yml for coverage, .codeclimate.yml, .editorconfig, pytest.ini, noxfile.py for session management, and a .git-blame-ignore-revs file for bulk reformatting commits so history stays readable.

towncrier compiles CHANGELOG.md from fragments kept in changelog/

The changelog is generated, not written by hand. The towncrier configuration says so in four lines:

[tool.towncrier]
    package = "salt"
    filename = "CHANGELOG.md"
    directory = "changelog/"

Contributors drop a fragment file into changelog/ describing their change, and the release process compiles those fragments into CHANGELOG.md using a Jinja template at changelog/.template.jinja. The changelog/ directory appears in the top-level listing, which confirms the layout.

This is why CHANGELOG.md can be large and still accurate in a repository where three branches are patched on the same day. Change notes are collected as they happen rather than reconstructed at release time, which is the only way three parallel streams stay documented.

For someone evaluating the project, the practical tip is to read changelog/ rather than CHANGELOG.md if you want to know what is in flight, because fragments that have not been compiled yet are sitting in the directory. It is also the clearest available signal of how a change reaches a release.

Around it sit the other process documents: CONTRIBUTING.rst, SUPPORT.rst, POLICY.rst, SECURITY.md, AUTHORS, DEPENDENCIES.md, FIXED_TESTS.md, GAP5.md and MULTI_RING_DESIGN.md.

Four product names for the same engine, and one corporate sponsor behind it

The commercial product built on Salt has been renamed three times, and the README is candid about it. Salt powers VMware by Broadcom's VMware Salt, previously called Aria Automation Config, previously vRealize Automation SaltStack Config, previously SaltStack Enterprise. The original sponsor, SaltStack, was acquired by VMware in 2020, and VMware was itself acquired by Broadcom in 2023.

Where the code lives has not changed: it is at github.com/saltstack/salt under the saltstack organisation, on the master branch, with an Apache 2.0 licence and the repository described as the home of the Salt Project.

The current arrangement is spelled out. The Salt Project remains an open source ecosystem that Broadcom supports and contributes to, Broadcom acts as the official sponsor and manager, and ensures the code integrity and quality of the Salt modules. The README notes that many of the core Salt Project contributors are also Broadcom employees, and that this team reviews and enhances the modules.

Set against that, the deployment reach is genuinely wide: Salt is stated to be found under the hood of products from Juniper, Cisco, Cloudflare, Nutanix, SUSE and Tieto. Salt also positions itself for network devices, naming switches and routers from a variety of vendors alongside operating systems.

Two things to weigh. Corporate sponsorship is why the project has three branches shipping patches within hours of each other, and that is a real benefit. It also means the roadmap, the review function and the funding all trace to one company. The README's own promotional line calls Salt the world's fastest, most intelligent and scalable automation engine; that is an assertion rather than a measurement, and the documented scope below it is the more useful basis for a decision.

Editorial conclusion

Adopt Salt when you have a Python-fluent operations team and want one event-driven tool for configuration management across operating systems and network devices, and accept that you are choosing a maintained branch rather than a version. Do not adopt it expecting a single upgrade path, since v3006, v3007 and v3008 all receive patches and you must track all three. Verify your Python version against the classifiers rather than requires-python, which allows anything from 3.8 up, and mirror the package repository if packages.broadcom.com availability matters to you.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. saltstack/salt on GitHub