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


Chronological Thread 
  • From: Noah Kantrowitz < >
  • To: Chef Dev < >
  • Subject: [chef-dev] Re: Re: Re: Re: Re: Re: Re: Re: Supported versions
  • Date: Tue, 3 Jun 2014 11:26:23 -0700


On Jun 3, 2014, at 1:51 AM, Lamont Granquist 
< >
 wrote:

> On Mon Jun  2 21:03:57 2014, Julian C. Dunn wrote:
>> On Jun 2, 2014, at 5:24 PM, Lamont Granquist 
>> <
>> <mailto: >>
>>  wrote:
>
>>> On 6/2/14, 7:11 AM, Jordan Wilberding wrote:
>>>> 
>>>> On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz
>>>> <
>>>>  
>>>> <mailto: >>
>>>>  wrote:
>>>> 
>>>> 
>>>>    On Jun 1, 2014, at 2:43 PM, Daniel DeLeo 
>>>> <
>>>>    
>>>> <mailto: >>
>>>>  wrote:
>>>> 
>>>>    >
>>>>    >
>>>>    > On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:
>>>>    >
>>>>    >> Can I also raise "what is our lifecycle policy for released
>>>>    versions
>>>>    >> of Chef". i.e. when can we stop releasing and supporting Chef 10?
>>>>    >>
>>>>    >> - Julian
>>>>    > Historically, we’ve maintained N and N - 1.
>>>> 
>>>>    Should probably have an explicit minimum time in addition to
>>>>    that, like "major versions will be supported for at least two
>>>>    years". That leaves room in case the chef-client team elects to
>>>>    release more often in the future.
>>>> 
>>>> 
>>>> This is an interesting point. The standard seems to be N and N-1.
>>>> While I understand the business case for having 2 years of support,
>>>> at the same time, we are moving towards CD, so I am curious what
>>>> others think about this in terms of measuring support in years vs
>>>> major releases.
>
>>> Can we cross this bridge once we actually find some things that we'd
>>> like to break backcompat on?  That cart is already lapping the horse
>>> before its barely gotten out of the gate….
>
>> It’s not about backcompat or breaking it, it’s about reducing
>> engineering burden on having to backport things from N to N-1 and
>> supporting ancient versions forever.
>
>> - Julian
> 
> We need to release a 1.0 first, and *then* we need to introduce a breaking 
> change that results in a 2.0, and we're currently releasing 0.x's.

I think we are possibly talking past each other. Some of this thread has been 
about Chef (the gem), some about ChefDK (the omnibus package), and some about 
chefdk (the gem).

--Noah


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




Archive powered by MHonArc 2.6.16.

§