Re: Re: Re: Re: Re: Re: Re: Cookbook Versioning Policy

One issue I wrestle with in applying semantic versioning to Chef is that while we version cookbooks, what we really care about is the end state of the cookbook’s resources, e.g., the applications that are installed by Chef. There is a non-trivial number of applications/products (e.g., OpenStack) that change dramatically in scope, features, and/or the way they are installed as they evolve through various releases. Simply saying that this is a new “incompatible” cookbook version seems to dramatically understate the matter.

Another concern I have is that applying semantic versioning to Chef can tend to be too nuanced. It is often difficult to tell whether something is a minor or patch update. Also, Chef doesn’t have the concept of to implementers and consumers of an interface which allows OSGi semantic versioning to know to increment the major vs. minor version number.

Has anyone considered using the major version number of a cookbook to correspond (somehow) to “significant” versions of the product or application being installed and reserving the minor and micro version for incompatible and compatible changes respectively? I agree that it would be nice to have release identifiers and build numbers would be useful, e.g., following the Ivy convention.

On 05/24/13, Greg Symons<> wrote: That’s a good point, and apparently there’s still a lot of discussion

about build numbers going on[1]. However, even prerelease identifiers,

which were in the 1.0.0 spec, will make Chef unhappy. My main point

being, we can’t start semverring cookbooks in a way that allows the

differentiation between forks and upstream releases without either

prerelease identifiers (which I don’t particularly like overloading for

this purpose) or build numbers (which make more sense to me as

site-specific portions of the version).



On Wed 21 Nov 2012 11:39:56 AM CST, Jamie Winsor wrote:

> While Berkshelf (and Solve) support the latest version of SemVer; it’s important to note that it is a release candidate and not final.


> Build numbers were not in the last finalized release (1.0).


> Jamie Winsor

> @resetexistence


> On Nov 21, 2012, at 12:15 PM, Greg Symons <> wrote:


>> On Wed 21 Nov 2012 11:07:26 AM CST, Torben Knerr wrote:

>>> +1 for build identifiers


>>> As Greg said, that would finally be a sane ways to differentiate

>>> forked community cookbooks from the upstream ones. As of today,

>>> there’s no sane way of doing this. For sure you could define a

>>> different cookbook location (like “:git => ‘my-fork-of-cookbook-xyz’”)

>>> in a Berksfile or Cheffile, but in the metadata.rb this information is

>>> lost again.


>>> There’s a similar discussion ongoing whether to add a url to the

>>> metadata.rb. I believe this is an attempt to solve the same problem,

>>> but in my opinion, adding the url is too much implemtenation detail.

>>> If we could just add something like version 1.0.1.something that

>>> uniquely identifies a forked version then we wouldn’t need something

>>> like an url in the metadata.rb.


>> Exactly. For a more concrete example, our convention (if we could:) is <upstream-major>.<upstream-minor>.<upstream-patch>+di.<build-number>.<sha>, or something like: 1.0.0+di.1.abcdef. The build number would be assigned by the build automation, and would not be checked into git, which is why we add the sha to the build number. This way, we will never conflict with an upstream metadata.rb, but can still have a divergent fork. But right now Chef pukes if you give it a version number that isn’t strictly <major>.<minor>.<patch>.


>> Greg