Chef 10.x won't be getting any new features, and there'd have to be an erlang version of the library to get support in the chef 11 server.Honestly, though, I'd much rather remove dependency solving from the server entirely. If we radically simplify environments to support only exact cookbook versions dependencies then its relatively straightforward to add versioning of roles to environments, which would solve a lot of wailing and gnashing of teeth.Here's my proposal so far: https://gist.github.com/danielsdeleo/7c55ebe39639928134dfIn this scenario, you'd still have x.y.z (+ etc) version numbers, but they'd be used for communication between developers (the "semantic" part of semver) and by tools such as berkshelf and librarian when resolving dependencies. Since the server wouldn't use the version numbers, we could relax the restrictions on them to support all the prerelease stuff without adding complexity to the dependency solver algorithm.--
On Saturday, March 30, 2013 at 11:13 AM, Mike wrote:Seth,This looks awesome! Can we expect this library to supplement cookbookversioning in Chef Server/Client/Solo so cookbooks can be SemVercompliant with prerelease and build numbers?-MOn Sat, Mar 30, 2013 at 1:24 AM, Seth Chisamore < " target="_blank"> > wrote:Ohai,We just open-sourced mixlib-versioning which is general purpose Ruby library that allows you to parse, compare version strings in multiple formats. This library was born out of work done in support of Omnibus, Omnitruck and our internal Jenkins build pipelines.The library has been published to Rubygems.org and source code is available on GitHub:We hope some people in the community find it useful!--Seth ChisamoreSoftware Development Engineer, Opscode, Inc.IRC, Skype, Twitter, Github: schisamo
Archive powered by MHonArc 2.6.16.