Lets try breaking it down like this. I'm speaking here as a community member, not as CTO of Chef Software. This is not a decision - it's a an opener for a public discussion.Chef (the code): works on Ruby 1.9.3 and up. Will stop supporting 1.9.3 when it is EOL.Chef Client (the omnibus package): Works on Ruby 1.9.3 now, may move ahead whenever we feel like it. Should be sooner than later, because faster.Chef DK (the omnibus package): Works on Ruby 2.0, and will move ahead whenever we can certify all the components work well together.Now, for what happens to bug fixes, security, etc:N: Fully supported, features, bug fixes, and securityN-1: 1 year of security (even if N moves past the release being N-1) for a stable major number release. Major, blocking bugs only.So, for example - if Chef 12 comes out in January 2015, Chef 11 would be EOL January 2016. If Chef 13 came out in March, Chef 12 is EOL March 2016. It would be on our backs as a community to make that work if we make major, back-compat breaking changes more than once a year.Chef Software's support policy may be longer than that (just like RHEL does extended support long after they stop publishing updates) or shorter.AdamOn Tue, Jun 3, 2014 at 2:00 PM, Lamont Granquist < " target="_blank"> > wrote:re-reading the quotes (my mail reader does a pretty good job of hiding them by default) apparently we are.On Tue Jun 3 11:26:23 2014, Noah Kantrowitz wrote:
On Jun 3, 2014, at 1:51 AM, Lamont Granquist < " target="_blank"> > wrote:
On Mon Jun 2 21:03:57 2014, Julian C. Dunn wrote:
On Jun 2, 2014, at 5:24 PM, Lamont Granquist < " target="_blank">
<mailto: " target="_blank"> >> wrote:
On 6/2/14, 7:11 AM, Jordan Wilberding wrote:
On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz
< " target="_blank"> <mailto: " target="_blank"> >> wrote:
On Jun 1, 2014, at 2:43 PM, Daniel DeLeo < " target="_blank">
<mailto: " target="_blank"> >> 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).
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.
Archive powered by MHonArc 2.6.16.