New Product Update: Introducing Semantic Versioning for Chef Workstation

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: 

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.  

Why We’re Moving to Loose Semantic Versioning 

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. 

 What Semantic Versioning Is 

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 

Loose Semantic Versioning 

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. 

What does Loose Semantic Versioning mean for Chef Workstation? When will we change version numbers? 

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. 

 How We Will Adopt Semantic Versioning for Chef Workstation 

• 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. 

What's Changing (and What's Not)

What is changing 

• 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) 

What is not changing 

• 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 

 Impact by Customer Type 

Platform and DevOps teams 

• Easier to automate upgrades 

• Patch releases can be safely auto‑consumed

• Clear signals for when extra testing is required (major releases) 

Security and Compliance teams 

• Patch versions clearly identify security and bug‑fix‑only releases

• Cleaner integration with vulnerability management and SBOM tooling

• Reduced ambiguity during audits and reviews 

Enterprise Change‑Management Teams 

• More predictable upgrade planning

• Clearer approval flows aligned to MAJOR vs MINOR vs PATCH changes

• Easier internal communication on upgrade risk 

How to Prepare for the Transition 

Here are a few practical steps to ensure a smooth experience: 

1. Review upgrade policies 

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 

2. Update automation and tooling 

If your scripts, CI pipelines, or internal documentation assume a date‑based version format, update them to expect SemVer-compatible versions. 

3. Train teams on version intent 

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 

4. Monitor release notes 

Each release will clearly document: 

• Whether changes are breaking

• What components are impacted

• Recommended upgrade paths 

 Looking Ahead 

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.