- From: Daniel DeLeo <
>
- To:
- Cc: "
" <
>, Chef Dev <
>
- Subject: [chef] Re: [chef-dev] Re: 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.