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

[Adam Jacob < >]

I'm stoked to see it be its own library - it makes total sense that it is. Just seems clearly useful. :)

Adam

On Mon, Jul 28, 2014 at 2:31 PM, Seth Vargo < " target="_blank"> > wrote:

I wanted to clear up two misconceptions:

1. Chef Sugar would get pulled into **Ohai**.

2. Chef Sugar is in use in other projects (see Omnibus), and therefore I think it should be it's own library.

I don't mind maintaining it, and I prefer the quick release cycles I can have with it. It's a very simple cookbook that does a gem install.

Seth

On Jul 28, 2014, at 2:19 PM, Adam Jacob < " target="_blank"> > wrote:

Perhaps we pull in the stable parts of Sugar?

Adam

On Mon, Jul 28, 2014 at 10:35 AM, Daniel DeLeo < " target="_blank"> > wrote:

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