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


Chronological Thread 
  • From: "Julian C. Dunn" < >
  • To: Chef Dev < >
  • Subject: [chef-dev] Re: Re: Re: Re: Re: Re: Supported versions
  • Date: Tue, 3 Jun 2014 00:03:57 -0400

On Jun 2, 2014, at 5:24 PM, Lamont Granquist < "> > wrote:

On 6/2/14, 7:11 AM, Jordan Wilberding wrote:
" type="cite">

On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz < " target="_blank"> > wrote:

On Jun 1, 2014, at 2:43 PM, Daniel DeLeo < "> > 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. 

" type="cite">
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

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




Archive powered by MHonArc 2.6.16.

§