[chef-dev] Re: Re: Re: Re: Re: Supported versions

[Noah Kantrowitz < >]

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail