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

[Mike < >]

Thanks for reviving.

Conversation continues on the ticket, please comment and watch/vote
there. Some Opscode interaction might be useful.

On Fri, Mar 22, 2013 at 4:36 PM, Torben Knerr 
<
 >
 wrote:
> Now that Cookbook Versioning Policy v0.1.0 is out
> (https://github.com/chef-community/cvp), it's a good time to revisit this
> discussion.
>
> Do you still need prerelease identifiers or build numbers for cookbooks?
>
> The limitation of the current versioning scheme to be strictly
> "<major>.<minor>.<patch>" is still one of the pain points for me.
>
> Created CHEF-4027 to bring up the discussion again:
> http://tickets.opscode.com/browse/CHEF-4027
>
> Cheers,
> Torben
>
>
> On Wed, Nov 21, 2012 at 7:33 PM, 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).
>>
>> [1]: https://github.com/mojombo/semver/issues/51
>>
>> Greg
>>
>>
>> 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
>>
>>
>>
>