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

[Torben Knerr < >]

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 < " target="_blank"> > 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 < " target="_blank"> > 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