[chef] Re: Re: Re: Re: Cookbook Versioning Policy

[Greg Symons < >]

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