[chef] Re: Re: Re: Re: Re: Re: Re: Berksfile question

[Jamie Winsor < >]

Hey Torben, 

Oh man, I didn't know that was actually a rule in SemVer - thanks for pointing that out! Since this is the case we could think about "choosing the best" branch.

I completely support the debate to have Chef play more nicely with SemVer 2.0.0.rc1. Let's keep that going ;)

-- 

Jamie Winsor

@resetexistence

https://github.com/reset

On Thursday, May 23, 2013 at 9:27 AM, Torben Knerr wrote:

On May 23, 2013 10:43 AM, "Jamie Winsor" < "> > wrote:
>
> We tag our software in Git whenever we make a release, however, it is not part of the SemVer convention do this. It's a good bet that you would see something named "v1.0.0" or "1.0.0", but tagging releases and this format is not a standardized thing.

Actually this is part of SemVer 1.0.0 [1]:

"When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0"."

> We could create some sort of Github default location which would pull the tar.gzs made available from the presence of tags, but we would have to assume this tagging naming convention (and whatever else pops up that is "common") and there's still the question of "Why?". Do we really need to cling to the idea of Git/Github as the canonical place to pull artifacts from when our nodes do it every single day out of the actual artifact server (The Chef server)?
>

I think canonical depends on your workflow. For you it would be the artifact server, for me it would be the git location (not using chef server).

I would not want to have Berkshelf pulling tar.gzs as this is github specific, and I'm happy with how the git / github locations in Berksfile work today -- it would just be a nice addition if you would not have to specify the version you want in both metadata.rb and Berksfile.

> It's not currently debatable whether a given non-tagged branch should contain a final-looking version number because it's not possible to use anything other than SemVer 1.0 in cookbooks. It's also not a standardized rule to change your version number to the next target release. It's understood that any commits which happen after the version was tagged but before the version in the actual version file is incremented are part of a future release.
>

IMHO this is debatable because it's a limitation in Chef rather than in SemVer. SemVer 1.0.0 allows pre-release versions like "1.0.0-dev" but Chef does not [2] :-(

If we don't debate over it it will probably never change ;-)

[1] http://semver.org/spec/v1.0.0.html
[2] http://tickets.opscode.com/browse/CHEF-4027