As Chef Workstation continues to evolve to meet the needs of modern DevSecOps teams, we’re making an important change to how we version future releases.
Starting with Chef Workstation 26, we are moving away from our historical dated versioning scheme and adopting loose Semantic Versioning (SemVer). This change applies to:
The Chef Workstation 26 major release
All minor and patch releases for 26.x
All future minor and patch releases for Chef Workstation 25.x beyond 25.12.x
This update is about improving clarity, predictability,and confidence for our customers—especially those managing upgrades at scale or embedding Workstation into automated pipelines.
Let’s walk through what this means, why we’re doing it, and how you can prepare.
Historically, Chef Workstation versions were tied to release dates (for example, 25YYMMDD). While this system worked, it often made it difficult to answer questions customers care deeply about:
Is this release safe to upgrade to?
Does this include breaking changes?
Can I auto-upgrade patch releases without risk?
Semantic Versioning—expressed as MAJOR.MINOR.PATCH—directly answers those questions by embedding intent into the version number itself.
Under Semantic Versioning:
MAJOR versions introduce breaking or backward‑incompatible changes
MINOR versions add new functionality in a backward‑compatible way
PATCH versions deliver backward‑compatible bug fixes and security updates
Our definition of loose semantic versioning relaxes these constraints slightly for software that is comprised of many components, like Workstation. Because each component may introduce breaking changes, but many components are rarely used, we are choosing to only consider changes in certain products as significant. This generally means that only changes in major products – Infra Client, InSpec, Habitat, Test Kitchen, or Knife – will result in a major version bump. We explicitly document these choices in detail below.
While Loose Semantic Versioning is a weaker claim than Full Semantic Versioning, we feel moving from date-based versions (which gave no assurance whatsoever) to a model that provides limited assurance while maintaining sensible release practices is a fair compromise.
Since Workstation is a bundle of other components, it does not generally have features itself – only those expressed by its components. So, when will the version bumps occur?
The Progress Chef policy for version bumps will be as follows for Chef Workstation:
When Chef Infra Client, Chef InSpec, Chef Habitat, Test Kitchen, or Knife has a major version bump, Workstation will have a major version bump. If multiple products have a major version bump in the same release, the workstation major version will only be bumped once.
Likewise, when Client, InSpec, Habitat, Test Kitchen, or Knife have a minor version bump, the Workstation minor version will bump at least once.
For all other products, we will generally align tool upgrades with the major applications. That said, we will follow SemVer loosely and on a case-by-case basis. In particular, we may treat a major bump in a component as a minor bump in Workstation. For example, a major version change in Cookstyle might be expressed as a minor version change in Workstation.
Customers should rely on SemVer for major product lines (Client, InSpec, Habitat, Knife, and Test Kitchen) but continue to treat Workstation as a “currently working bundle” for all other tools.
Chef Workstation 26 becomes the first SemVer‑based major release
Chef Workstation 25.x will also follow SemVer for all remaining minor and patch updates, with 25.13 and beyond being SemVer-based.
Importantly, there is no functional regression introduced solely because of this versioning change. The shift is about clarity—not disruption.
Version numbers will explicitly communicate change impact
Release notes will clearly map to major, minor, or patch intent
Upgrade risk is easier to assess at a glance
Better compatibility with tooling that expects SemVer (CI/CD systems, dependency scanners, package managers)
Your existing Chef Workstation installation does not suddenly break
Supported platforms and packaging formats remain the same
Our commitment to stability, security fixes, and predictable releases continues
Easier to automate upgrades
Patch releases can be safely auto‑consumed
Clear signals for when extra testing is required (major releases)
Patch versions clearly identify security and bug‑fix‑only releases
Cleaner integration with vulnerability management and SBOM tooling
Reduced ambiguity during audits and reviews
More predictable upgrade planning
Clearer approval flows aligned to MAJOR vs MINOR vs PATCH changes
Easier internal communication on upgrade risk
Here are a few practical steps to ensure a smooth experience:
If you have internal rules around upgrades (for example, auto‑updating “safe” versions), consider aligning them to:
Auto‑approve PATCH
Regularly review MINOR
Plan and test MAJOR
If your scripts, CI pipelines, or internal documentation assume a date‑based version format, update them to expect SemVer-compatible versions.
Make sure teams understand that:
26.0.1 is safer to adopt than 26.1.0
27.0.0 will require deeper validation than 26.2.0
Each release will clearly document:
Whether changes are breaking
What components are impacted
Recommended upgrade paths
This shift to Loose Semantic Versioning is part of a broader effort to make Chef Workstation easier to adopt, easier to upgrade, and easier to trust—especially in large, automated, and regulated environments.
We’re excited about the consistency and transparency this brings, and we believe it will make life simpler for everyone who relies on Chef Workstation as a core part of their development and infrastructure workflows.
As always, we welcome feedback and questions from our customers and community.