[chef-dev] Re: ANNOUNCE: RFC: Cookbook Versioning Policy

[Fletcher Nichol < >]

On Tuesday, 18 December, 2012 at 7:58 AM, Mike wrote:
> Ohai Chefs!
> 
> First off, Happy Tuesday!
> 
> After the Chef Summit 2012, where the topic of Cookbook Versioning was
> discussed by many, Kevin Christen reached out on the dev list with a
> proposal to start by figuring out what each part of a cookbook's
> version number should encompass.
> 
> We wrote back and forth a bit, and Kevin did most of the heavy lifting
> (writing?), and we are now happy to announce that we're looking for
> comments from both Opscode and the community.
> 
> For your review:
> https://docs.google.com/document/pub?id=1DuZ0g98vFV7-I23c6_7prKBnWSgVb7s0cU0EgeIidc0
> (should be world-viewable)
> 
> The goal is that by having a documented changes-to-revision policy, we
> will be able to produce better predictability when it comes to
> releases, and have a higher degree of predictability when using
> someone else's code.
> 
> Please feel free to email Kevin & myself directly with your feedback,
> or respond to this thread on the list, so others can chime in.
> 
> Looking forward to hearing your thoughts and opinions,
> Mike Fiedler & Kevin Christen

Howdy all,

As I just came across this email (so far behind on mailing list reading), I 
thought I'd add a couple of thoughts.
First off, great work, this really helps make explicit what for me has been a 
very implicit or gut feeling when specifying new release version number.
Despite the link to http://semver.org, it still would be nice to at least ;
have a note about the intention of versions < 1.0.0. If nothing else, it's a 
chance to emphasize that the author considers this cookbook non-production 
ready or subject to large internal/external refactorings. Personally, I need 
to cut tons of 1.0.0 releases since I know most are used in production :)
I generally agree with a major bump needed on an attribute value change, 
there might be times where that's too heavyweight for me. The example that 
comes to my mind (I've agonized about this in the past) is changing the 
default installed Ruby version in the RVM cookbook. Should updating a value 
from "1.9.3-p0" to "1.9.3-p125" constitute a major bump? Maybe not. How about 
a change from "1.8.7-p371" to "1.9.3-p374"? In this case I probably would 
bump the major since it's a radically different Ruby version with unforeseen 
consequences. What do others think here?
Is this the right place to talk about how you might use versioning (as it 
currently stands) to denote a master/development version vs. a properly 
released cookbook? For example, I've been using odd patch numbers to signify 
a development/in-progress cookbook and even numbers for a release. So if my 
last release version was 1.2.4, I'd leave metadata.rb in Git referring to 
1.2.5 and the next patch release would be 1.2.6 (assuming that a minor or 
major bump was not required). Granted this is just one strategy but until we 
get more bits to play with there seems to be limited options here.
That's all I have for the moment, great job Mike and Kevin!

Cheers,

Fletcher