[chef-dev] Re: Re: Re: Chef Server Support Policy?

["Scott M. Likens" < >]

Mike,

Looks like 11.1.x is still supported as they upgraded openssl for 11.1.6 (and 
disabled sslv3)

Unofficial answer of course


On 2/18/15 11:32 AM, Mike wrote:
> Did anything ever come of this?
> 
> 
> On Thu, Nov 27, 2014, 13:46 Stephen Delano 
> <
 
> <mailto:
 >>
>  wrote:
> 
>     Ohai!
> 
>     I've pulled the following from an email I sent out at Chef earlier
>     in the year, and it looks remarkably similar to RFC015:
> 
>         1) We will always support $(CURRENT_MAJOR - 1) with security
>         fixes as they become apparent.
>         2) We will always support $(CURRENT_MAJOR).$(CURRENT_MINOR) with
>         security fixes as they become apparent.
> 
> 
>     The context of the email was centered around security
>     vulnerabilities, but can be extended to major bugfixes as well.
>     Given the above rules, I've put together the following table of Chef
>     Server version patch support (we still support all the versions we
>     ship):
> 
>       Version Security Fixes  Bug Fixes
>     Chef Server       12.0.0          
>       11.1.5          Only Major
>       10.x            
>     Enterprise Chef   11.2.5          Only Major
>       1.4.15          
> 
> 
>     I'll work on getting this formalized via RFC early next week, as
>     well as take care of the maintainers. Enjoy the holiday!
> 
>     -Stephen
> 
>     On Thu, Nov 27, 2014 at 7:08 AM, Mike 
> <
 
>     
> <mailto:
 >>
>  wrote:
> 
>         Ohai, turkeys! (Thanksgiving joke, I kid, I kid)
> 
>         With the awesome announcement of Chef 12 being released, I was
>         looking for some verbiage around Chef Server 11 continued
>         support policy, and was unable to see anything along those lines.
> 
>         RFC015 [1] does a great job at scoping out how chef-client
>         versions will be supported (Latest , Latest -1, backports, etc).
>         It doesn't address release cycles yet, I'm sure that will come.
> 
>         However, it does not address the server-side components, nor
>         does RFC030 [2] show any maintainers yet for Server component,
>         nor Client components yet.
> 
>         I understand these are relatively new RFCs, but I do understand
>         that there's significant effort in play by representatives at
>         Chef Inc that, for lack of a better term, 'control' the
>         lifecycle of Chef Server - development and commit rights,
>         release cycles et al.
> 
>         It would be somewhat foolhardy for someone who does not have the
>         background, experience or resources to propose a particular
>         maintenance cycle for elements that are not in any way part of
>         the Things I Do every day, so I propose:
> 
>         - current maintainers of Chef Server be added to RFC030, so we
>         know who to talk to
>         - current thoughts/existing procedures on Chef Server
>         maintenance be written down, so we can then openly discuss how
>         to improve these as an RFC Proposal.
> 
>         I'm totally open to discussing this further - so feel free to
>         toss in your ideas, desires and dreams.
> 
>         [1]: 
> https://github.com/opscode/chef-rfc/blob/master/rfc015-chef-12.md
>         [2]: 
> https://github.com/opscode/chef-rfc/blob/master/rfc030-maintenance-policy.md
> 
>         Best,
>         -Mike Fiedler, Community Individual
> 
> 
> 
> 
>     -- 
>     Stephen Delano
>     Software Development Engineer
>     Opscode, Inc.
>     1008 Western Avenue
>     Suite 601
>     Seattle, WA 98104
> 
> !DSPAM:54e4e8d75541804284693!

Attachment: signature.asc
Description: OpenPGP digital signature