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

[Lamont Granquist < >]

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.