Chef Server Support Policy?


#1

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


#2

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):

VersionSecurity FixesBug FixesChef Server12.0.011.1.5Only Major10.xEnterprise
Chef11.2.5Only Major1.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 miketheman@gmail.com 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.

Best,
-Mike Fiedler, Community Individual


Stephen Delano
Software Development Engineer
Opscode, Inc.
1008 Western Avenue
Suite 601
Seattle, WA 98104