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

[Lamont Granquist < >]

On 6/4/14, 9:37 PM, Adam Jacob wrote:
> Lets try breaking it down like this. I'm speaking here as a community 
> member, not as CTO of Chef Software. This is not a decision - it's a 
> an opener for a public discussion.
>
> Chef (the code): works on Ruby 1.9.3 and up. Will stop supporting 
> 1.9.3 when it is EOL.
> Chef Client (the omnibus package): Works on Ruby 1.9.3 now, may move 
> ahead whenever we feel like it. Should be sooner than later, because 
> faster.
> Chef DK (the omnibus package): Works on Ruby 2.0, and will move ahead 
> whenever we can certify all the components work well together.
>
> Now, for what happens to bug fixes, security, etc:
>
> N: Fully supported, features, bug fixes, and security
> N-1: 1 year of security (even if N moves past the release being N-1) 
> for a stable major number release.  Major, blocking bugs only.
>
> So, for example - if Chef 12 comes out in January 2015, Chef 11 would 
> be EOL January 2016. If Chef 13 came out in March, Chef 12 is EOL 
> March 2016. It would be on our backs as a community to make that work 
> if we make major, back-compat breaking changes more than once a year.
>
> Chef Software's support policy may be longer than that (just like RHEL 
> does extended support long after they stop publishing updates) or shorter.
Would love to see exactly that written up as a more official policy 
since that is what everyone generally seems to agree to.

Note, however, that for Chef 10 we supported it longer than a year, and 
did major feature back-ports, and tons of bug fixes, which took 
considerable amounts of time.  For every minor release of 11 that we cut 
there was typically a minor release of 10 with a half dozen backported 
fixes at least.

What's the definition of "major, blocking bugs only"?  Because to a 
customer still stuck on N-1, every bug they hit is a major blocking bug 
to them.  Also, if we could limit minor releases of N-1 to only 
quarterly or every-other-N-release, that might help -- basically set an 
expectation that if you're on N-1 that response times are going to be 
stepped down (exceptions made for security releases and regression 
patches, of course).