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

[Jamie Winsor < >]

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