Puppet Release Notes
Puppet Open Source
- Puppet 4.0
- Puppet 3.7
- Puppet 3.6
- Puppet 3.5
- Puppet 3.0 through 3.4
- Puppet 2.7
- Puppet 2.6
- Puppet 0.25
- Puppet 0.24
- Puppet 0.23
Maintenance and Security Branches
- Puppet Enterprise 3.7
- Puppet Enterprise 3.3
- Puppet Enterprise 3.2
- Puppet Enterprise 3.1
- Puppet Enterprise 3.0
- Puppet Enterprise 2.8
- Puppet Enterprise 2.7
- Puppet Enterprise 2.6
- Puppet Enterprise 2.5
- Puppet Enterprise 2.0
- Puppet Enterprise 1.2 (receiving security fixes until April, 2013)
About Version Numbers
Puppet Labs’ Open Source Projects
All of our open source projects — including Puppet, PuppetDB, Facter, and Hiera — use semantic versioning (“semver”) for their version numbers. This means that in an
x.y.z version number, the “y” will increase if new features are introduced and the “x” will increase if existing features change or get removed.
Our semver promises only refer to the code in a single project; it’s possible for packaging or interactions with new “y” releases of other projects to cause new behavior in a “z” upgrade of Puppet.
Historical note: In Puppet versions prior to 3.0.0 and Facter versions prior to 1.7.0, we weren’t using semantic versioning.
Since Puppet Enterprise bundles a lot of interrelated software together, it doesn’t use semantic versioning. In an
x.y.z version number, the “z” will increase for patch releases that make only minor changes to capabilities, and the “x.y” portion will increase for major new releases.
Before upgrading, you should skim our page of advice about upgrading Puppet.
The short version is that you should upgrade when you’re ready to upgrade, skim the release notes first, reserve some time for testing, upgrade the Puppet master first, and roll out upgrades in stages.
Finding Specific Fixes
The Roadmap Tracker lists tickets closed for each release.