[chef-dev] Re: Re: [chef] Chef Sugar v2.1.0

Chronological Thread 
  • From: Daniel DeLeo < >
  • To:
  • Cc: " " < >, Chef Dev < >
  • Subject: [chef-dev] Re: Re: [chef] Chef Sugar v2.1.0
  • Date: Mon, 28 Jul 2014 10:35:39 -0700

On Monday, July 28, 2014 at 10:08 AM, Adam Jacob wrote:

> Should we start packaging sugar up as a dep of Chef, both in the 
> chef-client and the chef-dk?
> That way we would just pick up the enhancements as we go, and it could 
> maintain a separate release cadence.  
> Adam

The tricky part of that is, if chef-sugar needs/wants to make a breaking 
change, then we have to decide whether or not we pull the update in to 
chef-client. If we *do* pull it in, then chef-client is making a breaking 
change and we should rev the major version number, which we may not want to 
do. If we *don’t* pull it in, then we have to pin our dependency to an older 
version, which will conflict with the newer version if someone tries to use 
it. More concretely, chef-client would have a dependency like “chef-sugar”, 
“~>2.1”. Seth realizes he can make feature X 1000% awesome-er if he changes 
something in a way that’s not completely backwards compat, so he releases 
sugar 3.0. Upon trying to load it, rubygems will see I’ve already loaded 
2.1.x and complain.

I’m definitely in favor of pulling at least some chef-sugar features into 
core. I think a good way to do it that works well with the technologies we’re 
stuck with (ruby/rubygems dependency model) and lets the individual projects 
release at their own pace is to have chef-sugar be the experimental/“future” 
features, and move them into core completely once they’re stable and accepted 
by the community as “good”. We probably need to coordinate a bit to have one 
implementation defer to the other so things don’t go haywire if you have 
versions of chef-sugar and chef-client that implement the same behavior.

Noah also made a good point last we brought this up, that if we have a 
dependency will the sole purpose of adding features to chef, but the project 
doesn’t follow our (currently TBD) governance model, then it’s kind of an end 
run around the governance policy. It should be up to Seth if he wants to be 
the “BDFL” of chef-sugar or not.

Anyway, tl;dr, there’s some stuff to figure out implementation-wise but I’m 
in favor in principle.

Daniel DeLeo

Archive powered by MHonArc 2.6.16.