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.
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
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.