Re: Re: Chef Server Support Policy?


#1

Did anything ever come of this?

On Thu, Nov 27, 2014, 13:46 Stephen Delano stephen@opscode.com 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):

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


#2

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 <stephen@opscode.com
mailto:stephen@opscode.com> 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 <miketheman@gmail.com
<mailto: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.

    [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!