On Tuesday, 18 December, 2012 at 7:58 AM, Mike wrote:
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:
(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
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!