So... Where is the disagreement then? The standard way works, chef-client works for 1.9.3 and up, and... ?
Adam
On Jun 1, 2014, at 4:51 PM, Daniel DeLeo < "> > wrote:
> I reply-all failed, sorry for the double post, Noah.
>
>>>
>>> ChefDK requires ruby 2.0+. It would not be difficult to change the one or two parts of the code that use Ruby 2.0 features. That said, 1.9.3 is in maintenance mode, only getting security updates and is scheduled for EOL next February. I would assume that people managing their own ruby environments are using some sort of version management tooling (rvm/rbenv/chruby) and all the tools I’m familiar with work on 2.0, so I don’t see this as an onerous requirement. I’m willing to be convinced otherwise if someone has a compelling story.
>>
>>
>> Because omnibus-chef has been shipping with 1.9.3, I think that needs to be supported until those versions of Chef are EOL'd.
>>
>> --Noah
>
> I don’t understand. If you’re gonna install ChefDK the app into omnibus chef-client, why wouldn’t you just get the ChefDK package instead? Chef client will continue to support 1.9.3 at least until 1.9.3 is EOL but more likely until 11.x is EOL.
Because omnibus was the officially sanctioned way to install workstations for a long time. It is written into documentation, provisioning systems, you name it. Switching involves changing packages, changing paths, changing versions of potentially large numbers of tools. You can't pretend everyone will use the new packages in anything less than a full multi-year deprecation cycle. As such, if you want to have this new tool (for the record, I'm still very much opposed) you need to exist in the ecosystem that people actually use.
--Noah
Archive powered by MHonArc 2.6.16.