[chef] Re: Re: Cookbook Versioning Policy

[Greg Symons < >]

Topic 1 will be a bit of work, since Chef's Version object currently 
doesn't store the version as a string, and in the brief look I saw of 
the postgres schema for Chef 11 at the summit, it looks like it will be 
stored there as major, minor, patch. While this will support a minimal 
version of the semver spec, it precludes the use of prerelease and build 
identifiers. For us, build identifiers are important so that we can 
distinguish between upstream and fork versions of community cookbooks. 
Build identifiers are also useful when rapidly iterating on a cookbook, 
so that you don't have to bump the version on every commit. I've noticed 
that when using Berkshelf with a Chef server, it only downloads a new 
version of the cookbook if the version has actually changed; uploading 
the same version with new content doesn't work. I personally agree with 
this behavior, so I wouldn't want Jamie to change it:), but it means I 
need another piece of versioning information that I can have my build 
automation bump that doesn't have _real_ semantic meaning.

Greg

On 11/17/2012 09:23 AM, Mike wrote:
> Hi Kevin,
>
> This is really a great question. In the recent Chef Community Summit,
> I raised the topic for discussion, and it seems that everyone agrees
> with the SemVer approach, and now we have to do a few things:
>
> 1. Ensure the tools can understand SemVer version strings - from Chef,
> Knife, etc to potentially extending Librarian, Berkshelf, Knife-spork,
> et al.
>
> 2. Define what constitues the amount of change for each level of versioning.
>
> I think the second one might be a good place to start, and
> unfortunately I don't think there's any documents published yet. I'd
> be happy to collaborate with you to come up with some drafts and see
> what makes most sense and then we can push it up for community review.
>
> Thoughts?
> -Mike Fiedler
>
> On Fri, Nov 16, 2012 at 11:02 PM, Kevin Christen
> <
>  >
>  wrote:
> > My organization has been using chef-solo for about 9 months, and we're
> > making the move to chef server. I'm going to need to provide guidance to
> > cookbook developers on bumping cookbook versions. I plan to follow the
> > semantic versioning (http://semver.org/) guidelines, where a non-backward
> > compatible change results in a major version bump, a backward compatible
> > change results in a minor version bump, and anything else results in a micro
> > version bump.
> >
> > I think I can provide guidance on what kind of cookbook changes are backward
> > compatible and what kinds aren't, but I imagine some else has already done
> > that. Are there existing cookbook versioning policy documents that I could
> > rely on?
> >
> > Thanks,
> > Kevin Christen