On Jun 3, 2014, at 1:51 AM, Lamont Granquist
< >
wrote:
On Mon Jun 2 21:03:57 2014, Julian C. Dunn wrote:
On Jun 2, 2014, at 5:24 PM, Lamont Granquist
<
<mailto: >>
wrote:
On 6/2/14, 7:11 AM, Jordan Wilberding wrote:
On Sun, Jun 1, 2014 at 11:55 PM, Noah Kantrowitz
<
<mailto: >>
wrote:
On Jun 1, 2014, at 2:43 PM, Daniel DeLeo
<
<mailto: >>
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).
Archive powered by MHonArc 2.6.16.