[chef] Re: looking for branching and release strategy doc

[Daniel DeLeo < >]

On Tuesday, March 22, 2011 at 2:01 PM, KC Braunschweig wrote:

Apologies if this is a well answered question, but I'm looking for a
doc on the opscode site or somewhere that specifically documents the
branching and release strategy used in the management of the chef open
source code itself. Looking at previous versions and the branches on
GitHub, you can get a rough idea, but for corporate purposes, it would
be nice to see an official document. Something to answer questions
like:
- implicit meaning behind major/minor version number changes
- is there an official "unstable" branch besides head?
- will there be an official "stable" branch?
- what are the timelines and criteria for moving features to "stable"?
- specific policies regarding timelines and beta/RC releases as well
as major releases?

Setting this sort of policy is an ongoing process. Once we release a "1.0" version, I think we'll start to follow something pretty close to the semantic versioning specification[1]. Until then, the minor version indicates breaking changes, and an updated patch version contains both backwards compatible feature additions/improvements and bug fixes.

As of right now, all new development happens on master. We use automated testing extensively to keep master in close to releaseable state at all times. New releases are generally cut from master. When development forks for a new version, we maintain the previous series as a stable branch, and new releases may be cut from that branch or master as needed. Our current policy is to support this branch with bug fixes for three months after the next major version is released[2]

Each new release goes through a beta/RC cycle, though there is no pre-set amount of time for a release to incubate, we consider feedback and bug reports from the community to decide when to release.

1. http://semver.org/

2. This is something new we are doing for 0.9.x -> 0.10.x

HTH,

-- 
Dan DeLeo

KC Braunschweig