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

  Original Message  
From: Lamont Granquist
Sent: Tuesday, June 3, 2014 04:51
To: Julian C. Dunn
Cc: Chef Dev
Subject: [chef-dev] Re: Re: Re: Re: Re: Re: Re: Supported versions

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.