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.
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 |
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.Best,-Mike Fiedler, Community Individual
Archive powered by MHonArc 2.6.16.