-
Notifications
You must be signed in to change notification settings - Fork 233
Branching Strategy
This document attempts to capture the details of our branching strategy for Puppet Server. This information is up-to-date as of 2015-11-19.
Puppet Server has 4 branches which align with Puppet Enterprise and Ruby Puppet.
-
master
For > 2.2.x development (Puppet "future" releases, TBD) -
stable
For 2.2.x development (Ruby Puppet 4.3.x, Puppet Agent 1.3.x, PE 2015.3.x) -
2.1.x
For 2.1.x development (no current dev branch in Ruby Puppet - aligned with Ruby Puppet 4.2.3, Puppet Agent 1.2.7, PE 2015.2.z) -
1.x
For 1.x development (Ruby Puppet 3.x, PE 3.8.z)
The 2.0 release series is compatible with Puppet 4.x as part of Puppet Collection 1 (PC1). The 2.1.0 and later releases are compatible with Puppet 3.x for remote agents only, and only Puppet 4.x satisfies the package dependency between Puppet Server and Puppet.
The 2.1.0 release included a URL compatibility layer that will allow Puppet 3.x agents to talk to Puppet Server 2.x. For more information, see https://tickets.puppetlabs.com/browse/SERVER-526.
Under normal circumstances, the stable
branch will be used for bugfix releases
off of the last stable "Y" release. PRs should only be targeted at stable if
they are intended to go out in a z/bugfix release, and all code merged into the
stable branch should be merged up to the master branch at regular intervals.
Most PRs should normally be targeted at the master
branch, which is where
feature work will be going on for the next X/Y release.
Ideally, as soon as a new x/major release is shipped (e.g. Puppet Server 2.0), that would become the stable branch and there would be no additional planned 1.x releases. Because of the drastic nature of the changes between Puppet 3 and Puppet 4, it's possible that we'll need to continue to do both 1.x and 2.x releases of Puppet Server for some period of time.
Where there are 4 branches at present, any change which would need to go into all 4 of the branches (i.e., critical maintenance fix) would need to be done against the 1.x branch first. Merge ups would then need to be done in the following sequence:
1.x -> 2.1.x -> stable -> master