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
Archive powered by MHonArc 2.6.16.