Supported versions


#1

With the Chef DK showing up, it looks like we need to chat about the list
of ways we as a community want to manage chef, ruby, and friends. A few
things we should answer:

  1. What versions of ruby is the chef gem supported on?

  2. What are the reqs for having a DK built for a platform ‘officially’?

What else? Noah? Ranjib?


#2

Can I also raise “what is our lifecycle policy for released versions
of Chef”. i.e. when can we stop releasing and supporting Chef 10?

  • Julian

On Sun, Jun 1, 2014 at 4:10 PM, Adam Jacob adam@opscode.com wrote:

With the Chef DK showing up, it looks like we need to chat about the list of
ways we as a community want to manage chef, ruby, and friends. A few things
we should answer:

  1. What versions of ruby is the chef gem supported on?

  2. What are the reqs for having a DK built for a platform ‘officially’?

What else? Noah? Ranjib?


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#3

hi,

  1. same as rubylang’s EOL (+6 months). i.e 1.9.3 -> 2.1.1 . it will be nice
    to have current stable ruby(2.1.1) as default in omnibus as well.
  2. i dont know how i can use chefdk currently. So I cant comment on chefdk.

ranjib

On Sun, Jun 1, 2014 at 1:14 PM, Julian C. Dunn jdunn@aquezada.com wrote:

Can I also raise “what is our lifecycle policy for released versions
of Chef”. i.e. when can we stop releasing and supporting Chef 10?

  • Julian

On Sun, Jun 1, 2014 at 4:10 PM, Adam Jacob adam@opscode.com wrote:

With the Chef DK showing up, it looks like we need to chat about the
list of
ways we as a community want to manage chef, ruby, and friends. A few
things
we should answer:

  1. What versions of ruby is the chef gem supported on?

  2. What are the reqs for having a DK built for a platform ‘officially’?

What else? Noah? Ranjib?


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#4

Is that because of ruby version, or something else?
On Jun 1, 2014 2:18 PM, “Ranjib Dey” dey.ranjib@gmail.com wrote:

hi,

  1. same as rubylang’s EOL (+6 months). i.e 1.9.3 -> 2.1.1 . it will be
    nice to have current stable ruby(2.1.1) as default in omnibus as well.
  2. i dont know how i can use chefdk currently. So I cant comment on chefdk.

ranjib

On Sun, Jun 1, 2014 at 1:14 PM, Julian C. Dunn jdunn@aquezada.com wrote:

Can I also raise “what is our lifecycle policy for released versions
of Chef”. i.e. when can we stop releasing and supporting Chef 10?

  • Julian

On Sun, Jun 1, 2014 at 4:10 PM, Adam Jacob adam@opscode.com wrote:

With the Chef DK showing up, it looks like we need to chat about the
list of
ways we as a community want to manage chef, ruby, and friends. A few
things
we should answer:

  1. What versions of ruby is the chef gem supported on?

  2. What are the reqs for having a DK built for a platform ‘officially’?

What else? Noah? Ranjib?


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#5

On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:

Can I also raise “what is our lifecycle policy for released versions
of Chef”. i.e. when can we stop releasing and supporting Chef 10?

  • Julian
    Historically, we’ve maintained N and N - 1.

On Sun, Jun 1, 2014 at 4:10 PM, Adam Jacob <adam@opscode.com (mailto:adam@opscode.com)> wrote:

With the Chef DK showing up, it looks like we need to chat about the list of
ways we as a community want to manage chef, ruby, and friends. A few things
we should answer:

  1. What versions of ruby is the chef gem supported on?

ChefDK requires ruby 2.0+. It would not be difficult to change the one or two parts of the code that use Ruby 2.0 features. That said, 1.9.3 is in maintenance mode, only getting security updates and is scheduled for EOL next February. I would assume that people managing their own ruby environments are using some sort of version management tooling (rvm/rbenv/chruby) and all the tools I’m familiar with work on 2.0, so I don’t see this as an onerous requirement. I’m willing to be convinced otherwise if someone has a compelling story.

  1. What are the reqs for having a DK built for a platform ‘officially’?
    For Chef to build and distribute it, we need to get a working omnibus build and add a build and test machine to the build cluster.

Side note, as a team, we’ve discussed the possibility of having external platform maintainers. The way omnitruck is designed right now, builds of a particular version need to be built for all platforms before the build can be published; that’s probably something we’d need to fix before we could do that (the release engineering team is working on using artifactory for build publishing, but I don’t know how that might change things).

What else? Noah? Ranjib?


[ Julian C. Dunn <jdunn@aquezada.com (mailto:jdunn@aquezada.com)> * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ (http://sdf.org/1/users/keymaker/) * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


Daniel DeLeo


#6

On Jun 1, 2014, at 2:43 PM, Daniel DeLeo dan@kallistec.com wrote:

On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:

Can I also raise “what is our lifecycle policy for released versions
of Chef”. i.e. when can we stop releasing and supporting Chef 10?

  • Julian
    Historically, we’ve maintained N and N - 1.

Should probably have an explicit minimum time in addition to that, like “major versions will be supported for at least two years”. That leaves room in case the chef-client team elects to release more often in the future.

On Sun, Jun 1, 2014 at 4:10 PM, Adam Jacob <adam@opscode.com (mailto:adam@opscode.com)> wrote:

With the Chef DK showing up, it looks like we need to chat about the list of
ways we as a community want to manage chef, ruby, and friends. A few things
we should answer:

  1. What versions of ruby is the chef gem supported on?

ChefDK requires ruby 2.0+. It would not be difficult to change the one or two parts of the code that use Ruby 2.0 features. That said, 1.9.3 is in maintenance mode, only getting security updates and is scheduled for EOL next February. I would assume that people managing their own ruby environments are using some sort of version management tooling (rvm/rbenv/chruby) and all the tools I’m familiar with work on 2.0, so I don’t see this as an onerous requirement. I’m willing to be convinced otherwise if someone has a compelling story.

Because omnibus-chef has been shipping with 1.9.3, I think that needs to be supported until those versions of Chef are EOL’d.

–Noah


#7

many reasons:

  1. Native gems: i use linux as my laptop(ubuntu 14.04), rest of team uses
    OSX. integration tests are also on lxc (in CI), out side CI both lxc &
    vagrant is used. lxc deps are linux specific, which we address using
    separate Gemfile or groups inside a Gemfile. all these details are captured
    in git. I dont know how i’ll address that with ChefDK.

  2. ChefDk being a system installer will require any installation script
    (provisioning developer machine for example) to have root privilege for
    execution. Currently its same as any other ruby project (bundle install).
    all our Gemfiles(s) have locked ruby versions (that reflect production) and
    I dont enforce any constrain on what ruby version manager developers should
    use.

  3. When we hit any bug in our chef tooling ( chefspec, berks, chef itself),
    Gemfiles allows us to test and fix those bugs against our patches. All of
    this is captured in out feature branches in our repo (which revert back the
    Gemfile to point to GA releases). This will be very complicated with chefdk
    (where we’ll capture the gem versions of chefdk?).

  4. lot of our dependency cookbooks (e.g. heavywaters, lusis’ etc) uses
    librarian. I still use berks., but I am keen to get rid of celluloid from
    non-jruby apps. And if that happens I have to modify chefdk.

  5. if rvm is installed, then GEM_PATH, and GEM_HOME cant screw with any
    ruby scripts, even if it has hardcoded exact omnibus ruby path. i had hit
    this with chef-omnibus. the only bulletproof way to address this was to
    invoke ruby scripts with env -i (i dont know of any better solution :frowning: ).
    till recently chef had a bug (PATH) which would inhibit invoking env -i
    chef-client , but now thats fixed. So even with all other system rubies i
    can now invoke any ruby script (including chef) with env -i , as long as it
    has a valid ruby in its #! line. With this, gem management is now really
    trivial and decoupled (use a shared gemset or have local .bundle &
    Bundler.setup as part of the scripts). this reduces the incentive to use
    chefdk (in fact any omnibus installation)

  6. Chef (11.8) is already available on ubuntu 14.04 , with ruby 1.9 & 2.0.
    So we can do a mixmode with system wide ruby+chef from apt repo, and
    individual scripts having their own stuff. ruby tooling has changed a lot
    on ubuntu, its not like 2 years back when we all were stuck with 1.8.7 even
    if 1.9 was out.

  7. after vagrant went omnibus, i had to rewrite lot of scripts only because
    vagrant’s plugin model was changed. I fear what will happen if chefdk
    introduces something like that,

these are some of the immediate concern i have, and i think im not the
intended user here (correct me if im wrong),

But i do understand that building berks is time consuming now (16 min on my
laptop), and might be more difficult on windows. ChefDK will definitely
shine there. In fact anyone, who wants to use a single version of chef for
really long time will be better off with chefdk.

best
ranjib

On Sun, Jun 1, 2014 at 2:19 PM, Adam Jacob adam@opscode.com wrote:

Is that because of ruby version, or something else?
On Jun 1, 2014 2:18 PM, “Ranjib Dey” dey.ranjib@gmail.com wrote:

hi,

  1. same as rubylang’s EOL (+6 months). i.e 1.9.3 -> 2.1.1 . it will be
    nice to have current stable ruby(2.1.1) as default in omnibus as well.
  2. i dont know how i can use chefdk currently. So I cant comment on
    chefdk.

ranjib

On Sun, Jun 1, 2014 at 1:14 PM, Julian C. Dunn jdunn@aquezada.com
wrote:

Can I also raise “what is our lifecycle policy for released versions
of Chef”. i.e. when can we stop releasing and supporting Chef 10?

  • Julian

On Sun, Jun 1, 2014 at 4:10 PM, Adam Jacob adam@opscode.com wrote:

With the Chef DK showing up, it looks like we need to chat about the
list of
ways we as a community want to manage chef, ruby, and friends. A few
things
we should answer:

  1. What versions of ruby is the chef gem supported on?

  2. What are the reqs for having a DK built for a platform ‘officially’?

What else? Noah? Ranjib?


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#8

On Sunday, June 1, 2014 at 3:32 PM, Ranjib Dey wrote:

many reasons:

  1. Native gems: i use linux as my laptop(ubuntu 14.04), rest of team uses OSX. integration tests are also on lxc (in CI), out side CI both lxc & vagrant is used. lxc deps are linux specific, which we address using separate Gemfile or groups inside a Gemfile. all these details are captured in git. I dont know how i’ll address that with ChefDK.
    You can use ChefDK alongside your current ruby env if you’d prefer to do that. Or, you can let ChefDK be your ruby environment. In either case, you can keep using bundler for anything you want to use outside of ChefDK.
  1. ChefDk being a system installer will require any installation script (provisioning developer machine for example) to have root privilege for execution. Currently its same as any other ruby project (bundle install). all our Gemfiles(s) have locked ruby versions (that reflect production) and I dont enforce any constrain on what ruby version manager developers should use.

  2. When we hit any bug in our chef tooling ( chefspec, berks, chef itself), Gemfiles allows us to test and fix those bugs against our patches. All of this is captured in out feature branches in our repo (which revert back the Gemfile to point to GA releases). This will be very complicated with chefdk (where we’ll capture the gem versions of chefdk?).
    We’re not there yet, but the goal is to continuously deliver ChefDK. At the moment you need a separate ruby environment if you want to develop, but as soon as your patch gets in, you should have a supported release of it the next day.

  1. lot of our dependency cookbooks (e.g. heavywaters, lusis’ etc) uses librarian. I still use berks., but I am keen to get rid of celluloid from non-jruby apps. And if that happens I have to modify chefdk.
    You can keep using librarian either by installing it to ChefDK (run chef gem install in your shell) or in a separate ruby environment.
  1. if rvm is installed, then GEM_PATH, and GEM_HOME cant screw with any ruby scripts, even if it has hardcoded exact omnibus ruby path. i had hit this with chef-omnibus. the only bulletproof way to address this was to invoke ruby scripts with env -i (i dont know of any better solution :frowning: ). till recently chef had a bug (PATH) which would inhibit invoking env -i chef-client , but now thats fixed. So even with all other system rubies i can now invoke any ruby script (including chef) with env -i , as long as it has a valid ruby in its #! line. With this, gem management is now really trivial and decoupled (use a shared gemset or have local .bundle & Bundler.setup as part of the scripts). this reduces the incentive to use chefdk (in fact any omnibus installation)
    Appbundler fixes this for the ChefDK app, chef-client/knife, berks, and TK by making the ruby executables unset those variables. It looks like this: https://gist.github.com/danielsdeleo/8a5af647ef2c0ff2b23c See also: https://github.com/opscode/appbundler/
  1. Chef (11.8) is already available on ubuntu 14.04 , with ruby 1.9 & 2.0. So we can do a mixmode with system wide ruby+chef from apt repo, and individual scripts having their own stuff. ruby tooling has changed a lot on ubuntu, its not like 2 years back when we all were stuck with 1.8.7 even if 1.9 was out.
    You can still have a “mix mode” if you want, ChefDK just provides a few more executables in the omnibus package. If you want ChefDK to be your one true ruby environment, that’s an opt-in thing.
  1. after vagrant went omnibus, i had to rewrite lot of scripts only because vagrant’s plugin model was changed. I fear what will happen if chefdk introduces something like that,

We’re not taking away the ability to use Chef as a library, and in fact we’d like to double down on the library-ness of chef-client code by extracting anything ChefDK the app uses to a separate gem (or gems). That’ll allow you to pull in just a subset of the chef code (and deps) that you need for a given task.

these are some of the immediate concern i have, and i think im not the intended user here (correct me if im wrong),

But i do understand that building berks is time consuming now (16 min on my laptop), and might be more difficult on windows. ChefDK will definitely shine there. In fact anyone, who wants to use a single version of chef for really long time will be better off with chefdk.

best
ranjib

Hope that clears some things up. The most important bit being that ChefDK doesn’t have to be your only ruby environment if you’re happily doing stuff with a different ruby environment, and the appbundler executables mean that things should work even if you want to use rvm for other ruby tasks.


Daniel DeLeo


#9

I reply-all failed, sorry for the double post, Noah.

ChefDK requires ruby 2.0+. It would not be difficult to change the one or two parts of the code that use Ruby 2.0 features. That said, 1.9.3 is in maintenance mode, only getting security updates and is scheduled for EOL next February. I would assume that people managing their own ruby environments are using some sort of version management tooling (rvm/rbenv/chruby) and all the tools I’m familiar with work on 2.0, so I don’t see this as an onerous requirement. I’m willing to be convinced otherwise if someone has a compelling story.

Because omnibus-chef has been shipping with 1.9.3, I think that needs to be supported until those versions of Chef are EOL’d.

–Noah

I don’t understand. If you’re gonna install ChefDK the app into omnibus chef-client, why wouldn’t you just get the ChefDK package instead? Chef client will continue to support 1.9.3 at least until 1.9.3 is EOL but more likely until 11.x is EOL.


Daniel DeLeo


#10

On Jun 1, 2014, at 4:51 PM, Daniel DeLeo dan@kallistec.com wrote:

I reply-all failed, sorry for the double post, Noah.

ChefDK requires ruby 2.0+. It would not be difficult to change the one or two parts of the code that use Ruby 2.0 features. That said, 1.9.3 is in maintenance mode, only getting security updates and is scheduled for EOL next February. I would assume that people managing their own ruby environments are using some sort of version management tooling (rvm/rbenv/chruby) and all the tools I’m familiar with work on 2.0, so I don’t see this as an onerous requirement. I’m willing to be convinced otherwise if someone has a compelling story.

Because omnibus-chef has been shipping with 1.9.3, I think that needs to be supported until those versions of Chef are EOL’d.

–Noah

I don’t understand. If you’re gonna install ChefDK the app into omnibus chef-client, why wouldn’t you just get the ChefDK package instead? Chef client will continue to support 1.9.3 at least until 1.9.3 is EOL but more likely until 11.x is EOL.

Because omnibus was the officially sanctioned way to install workstations for a long time. It is written into documentation, provisioning systems, you name it. Switching involves changing packages, changing paths, changing versions of potentially large numbers of tools. You can’t pretend everyone will use the new packages in anything less than a full multi-year deprecation cycle. As such, if you want to have this new tool (for the record, I’m still very much opposed) you need to exist in the ecosystem that people actually use.

–Noah


#11

So… Where is the disagreement then? The standard way works, chef-client
works for 1.9.3 and up, and… ?

Adam
On Jun 1, 2014 5:45 PM, “Noah Kantrowitz” noah@coderanger.net wrote:

On Jun 1, 2014, at 4:51 PM, Daniel DeLeo dan@kallistec.com wrote:

I reply-all failed, sorry for the double post, Noah.

ChefDK requires ruby 2.0+. It would not be difficult to change the one
or two parts of the code that use Ruby 2.0 features. That said, 1.9.3 is in
maintenance mode, only getting security updates and is scheduled for EOL
next February. I would assume that people managing their own ruby
environments are using some sort of version management tooling
(rvm/rbenv/chruby) and all the tools I’m familiar with work on 2.0, so I
don’t see this as an onerous requirement. I’m willing to be convinced
otherwise if someone has a compelling story.

Because omnibus-chef has been shipping with 1.9.3, I think that needs
to be supported until those versions of Chef are EOL’d.

–Noah

I don’t understand. If you’re gonna install ChefDK the app into omnibus
chef-client, why wouldn’t you just get the ChefDK package instead? Chef
client will continue to support 1.9.3 at least until 1.9.3 is EOL but more
likely until 11.x is EOL.

Because omnibus was the officially sanctioned way to install workstations
for a long time. It is written into documentation, provisioning systems,
you name it. Switching involves changing packages, changing paths, changing
versions of potentially large numbers of tools. You can’t pretend everyone
will use the new packages in anything less than a full multi-year
deprecation cycle. As such, if you want to have this new tool (for the
record, I’m still very much opposed) you need to exist in the ecosystem
that people actually use.

–Noah


#12

Response inline

On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz noah@coderanger.net
wrote:

On Jun 1, 2014, at 2:43 PM, Daniel DeLeo dan@kallistec.com wrote:

On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:

Can I also raise “what is our lifecycle policy for released versions
of Chef”. i.e. when can we stop releasing and supporting Chef 10?

  • Julian
    Historically, we’ve maintained N and N - 1.

Should probably have an explicit minimum time in addition to that, like
"major versions will be supported for at least two years". That leaves room
in case the chef-client team elects to release more often in the future.

This is an interesting point. The standard seems to be N and N-1. While I
understand the business case for having 2 years of support, at the same
time, we are moving towards CD, so I am curious what others think about
this in terms of measuring support in years vs major releases.


#13

On Mon, Jun 2, 2014 at 10:11 AM, Jordan Wilberding jordan@getchef.com wrote:

Should probably have an explicit minimum time in addition to that, like
"major versions will be supported for at least two years". That leaves room
in case the chef-client team elects to release more often in the future.

This is an interesting point. The standard seems to be N and N-1. While I
understand the business case for having 2 years of support, at the same
time, we are moving towards CD, so I am curious what others think about this
in terms of measuring support in years vs major releases.

I think that is generally how most software companies do it, so that
customers have an expectation of a fixed timeframe of support even if
the vendor decides to release more frequently (and/or change the
integer utilized in versioning their products).

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#14

On 6/2/14, 7:11 AM, Jordan Wilberding wrote:

Response inline

On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz <noah@coderanger.net
mailto:noah@coderanger.net> wrote:

On Jun 1, 2014, at 2:43 PM, Daniel DeLeo <dan@kallistec.com
<mailto:dan@kallistec.com>> wrote:

>
>
> On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:
>
>> Can I also raise "what is our lifecycle policy for released
versions
>> of Chef". i.e. when can we stop releasing and supporting Chef 10?
>>
>> - Julian
> Historically, we’ve maintained N and N - 1.

Should probably have an explicit minimum time in addition to that,
like "major versions will be supported for at least two years".
That leaves room in case the chef-client team elects to release
more often in the future.

This is an interesting point. The standard seems to be N and N-1.
While I understand the business case for having 2 years of support, at
the same time, we are moving towards CD, so I am curious what others
think about this in terms of measuring support in years vs major
releases.
Can we cross this bridge once we actually find some things that we’d
like to break backcompat on? That cart is already lapping the horse
before its barely gotten out of the gate…


#15

On Jun 2, 2014, at 5:24 PM, Lamont Granquist lamont@opscode.com wrote:

On 6/2/14, 7:11 AM, Jordan Wilberding wrote:

On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz noah@coderanger.net wrote:

On Jun 1, 2014, at 2:43 PM, Daniel DeLeo dan@kallistec.com wrote:

On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:

Can I also raise “what is our lifecycle policy for released versions
of Chef”. i.e. when can we stop releasing and supporting Chef 10?

  • Julian
    Historically, we’ve maintained N and N - 1.

Should probably have an explicit minimum time in addition to that, like “major versions will be supported for at least two years”. That leaves room in case the chef-client team elects to release more often in the future.

This is an interesting point. The standard seems to be N and N-1. While I understand the business case for having 2 years of support, at the same time, we are moving towards CD, so I am curious what others think about this in terms of measuring support in years vs major releases.

Can we cross this bridge once we actually find some things that we’d like to break backcompat on? That cart is already lapping the horse before its barely gotten out of the gate….

It’s not about backcompat or breaking it, it’s about reducing engineering burden on having to backport things from N to N-1 and supporting ancient versions forever.

  • Julian

#16

On Mon Jun 2 21:03:57 2014, Julian C. Dunn wrote:

On Jun 2, 2014, at 5:24 PM, Lamont Granquist <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On 6/2/14, 7:11 AM, Jordan Wilberding wrote:

On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz
<noah@coderanger.net mailto:noah@coderanger.net> wrote:

On Jun 1, 2014, at 2:43 PM, Daniel DeLeo <dan@kallistec.com
<mailto:dan@kallistec.com>> wrote:

>
>
> On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:
>
>> Can I also raise "what is our lifecycle policy for released
versions
>> of Chef". i.e. when can we stop releasing and supporting Chef 10?
>>
>> - Julian
> Historically, we’ve maintained N and N - 1.

Should probably have an explicit minimum time in addition to
that, like "major versions will be supported for at least two
years". That leaves room in case the chef-client team elects to
release more often in the future.

This is an interesting point. The standard seems to be N and N-1.
While I understand the business case for having 2 years of support,
at the same time, we are moving towards CD, so I am curious what
others think about this in terms of measuring support in years vs
major releases.

Can we cross this bridge once we actually find some things that we’d
like to break backcompat on? That cart is already lapping the horse
before its barely gotten out of the gate….

It’s not about backcompat or breaking it, it’s about reducing
engineering burden on having to backport things from N to N-1 and
supporting ancient versions forever.

  • Julian

We need to release a 1.0 first, and then we need to introduce a
breaking change that results in a 2.0, and we’re currently releasing
0.x’s.


#17

Original Message
From: Lamont Granquist
Sent: Tuesday, June 3, 2014 04:51
To: Julian C. Dunn
Cc: Chef Dev
Subject: [chef-dev] Re: Re: Re: Re: Re: Re: Re: Supported versions

On Mon Jun 2 21:03:57 2014, Julian C. Dunn wrote:

On Jun 2, 2014, at 5:24 PM, Lamont Granquist <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On 6/2/14, 7:11 AM, Jordan Wilberding wrote:

On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz
<noah@coderanger.net mailto:noah@coderanger.net> wrote:

On Jun 1, 2014, at 2:43 PM, Daniel DeLeo <dan@kallistec.com
mailto:dan@kallistec.com> wrote:

On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:

Can I also raise "what is our lifecycle policy for released
versions

of Chef". i.e. when can we stop releasing and supporting Chef 10?

  • Julian
    Historically, we’ve maintained N and N - 1.

Should probably have an explicit minimum time in addition to
that, like “major versions will be supported for at least two
years”. That leaves room in case the chef-client team elects to
release more often in the future.

This is an interesting point. The standard seems to be N and N-1.
While I understand the business case for having 2 years of support,
at the same time, we are moving towards CD, so I am curious what
others think about this in terms of measuring support in years vs
major releases.

Can we cross this bridge once we actually find some things that we’d
like to break backcompat on? That cart is already lapping the horse
before its barely gotten out of the gate….

It’s not about backcompat or breaking it, it’s about reducing
engineering burden on having to backport things from N to N-1 and
supporting ancient versions forever.

  • Julian

We need to release a 1.0 first, and then we need to introduce a
breaking change that results in a 2.0, and we’re currently releasing
0.x’s.


#18

On Jun 3, 2014, at 1:51 AM, Lamont Granquist lamont@opscode.com wrote:

On Mon Jun 2 21:03:57 2014, Julian C. Dunn wrote:

On Jun 2, 2014, at 5:24 PM, Lamont Granquist <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On 6/2/14, 7:11 AM, Jordan Wilberding wrote:

On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz
<noah@coderanger.net mailto:noah@coderanger.net> wrote:

On Jun 1, 2014, at 2:43 PM, Daniel DeLeo <dan@kallistec.com
mailto:dan@kallistec.com> wrote:

On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:

Can I also raise "what is our lifecycle policy for released
versions

of Chef". i.e. when can we stop releasing and supporting Chef 10?

  • Julian
    Historically, we’ve maintained N and N - 1.

Should probably have an explicit minimum time in addition to
that, like “major versions will be supported for at least two
years”. That leaves room in case the chef-client team elects to
release more often in the future.

This is an interesting point. The standard seems to be N and N-1.
While I understand the business case for having 2 years of support,
at the same time, we are moving towards CD, so I am curious what
others think about this in terms of measuring support in years vs
major releases.

Can we cross this bridge once we actually find some things that we’d
like to break backcompat on? That cart is already lapping the horse
before its barely gotten out of the gate….

It’s not about backcompat or breaking it, it’s about reducing
engineering burden on having to backport things from N to N-1 and
supporting ancient versions forever.

  • Julian

We need to release a 1.0 first, and then we need to introduce a breaking change that results in a 2.0, and we’re currently releasing 0.x’s.

I think we are possibly talking past each other. Some of this thread has been about Chef (the gem), some about ChefDK (the omnibus package), and some about chefdk (the gem).

–Noah


#19

On Tue Jun 3 11:26:23 2014, Noah Kantrowitz wrote:

On Jun 3, 2014, at 1:51 AM, Lamont Granquist lamont@opscode.com wrote:

On Mon Jun 2 21:03:57 2014, Julian C. Dunn wrote:

On Jun 2, 2014, at 5:24 PM, Lamont Granquist <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On 6/2/14, 7:11 AM, Jordan Wilberding wrote:

On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz
<noah@coderanger.net mailto:noah@coderanger.net> wrote:

On Jun 1, 2014, at 2:43 PM, Daniel DeLeo <dan@kallistec.com
<mailto:dan@kallistec.com>> wrote:

>
>
> On Sunday, June 1, 2014 at 1:14 PM, Julian C. Dunn wrote:
>
>> Can I also raise "what is our lifecycle policy for released
versions
>> of Chef". i.e. when can we stop releasing and supporting Chef 10?
>>
>> - Julian
> Historically, we’ve maintained N and N - 1.

Should probably have an explicit minimum time in addition to
that, like "major versions will be supported for at least two
years". That leaves room in case the chef-client team elects to
release more often in the future.

This is an interesting point. The standard seems to be N and N-1.
While I understand the business case for having 2 years of support,
at the same time, we are moving towards CD, so I am curious what
others think about this in terms of measuring support in years vs
major releases.

Can we cross this bridge once we actually find some things that we’d
like to break backcompat on? That cart is already lapping the horse
before its barely gotten out of the gate….

It’s not about backcompat or breaking it, it’s about reducing
engineering burden on having to backport things from N to N-1 and
supporting ancient versions forever.

  • Julian

We need to release a 1.0 first, and then we need to introduce a breaking change that results in a 2.0, and we’re currently releasing 0.x’s.

I think we are possibly talking past each other. Some of this thread has been about Chef (the gem), some about ChefDK (the omnibus package), and some about chefdk (the gem).

re-reading the quotes (my mail reader does a pretty good job of hiding
them by default) apparently we are.

so as far as chef goes, every version we have to maintain has a very
high cost in the time spent backporting and the time spent building and
releasing. if there is any policy other than N-1 and N, it would need
a lot of justification for the cost. TANSTAAFL.