[chef-dev] Re: CHEF-3788: More restrictive gem dependencies?

Chronological Thread 
  • From: "Julian C. Dunn" < >
  • To:
  • Subject: [chef-dev] Re: CHEF-3788: More restrictive gem dependencies?
  • Date: Thu, 24 Jan 2013 18:19:07 -0500

On Thu, Jan 24, 2013 at 5:46 PM, Bryan McLellan < " target="_blank"> > wrote:
Grégory has suggested in CHEF-3788  that the gem dependencies be more restrictive after the recent incident where Moneta 0.7.0 was released and the API was not backward compatible (CHEF-3721).

In the past we've been restrictive about gems that have had similar issues, particularly with slow responses, like JSON, but overall we have been more optimistic to get the benefits of new releases of libraries without having to make a new release of Chef. In the case of JSON, we occasionally have tickets where people want to bump the version because we're starting to cause dependency resolution failures with other tools that use Chef as a library.

But maybe it would help if we were at least pessmistic about major version changes, e.g. ~> x.y.  Anyone have other opinions to add?

I was actually just working my way up to an e-mail about this, because I'm in the middle of packaging Chef for Fedora and they have far newer versions of Gems -- like JSON -- than Chef's gemspec would suggest work.

My problem with being so restrictive about Gem versions is that few people actually go back periodically and see if such restrictions are still necessary.

I'm pretty sure the extremely pessimistic pinning on JSON can be removed, but how can I be sure? Is it just a matter of running Chef's unit tests and if they pass on the new Gem, I can submit a pull request to remove it?

- Julian

Archive powered by MHonArc 2.6.16.