; > >>
> > > > >> Having 3 releases a year sounds OK, but if they're all equivalent
> > and
> > > > bugfix releases are produced for the most
> > > > >> recent 2 or 3 releases, anyone wanting to run on an "in support"
> > > > release
> would be good. I suppose that if the burden of having that many
> > in-support
> > > releases proves too heavy,
> > > as you say we could reconsider.
> > >
> > > Andrew Schofield
> > >
> > >
> > &
nting to run on an "in support"
>>> release of Kafka has to upgrade every 8-12 months.
>>>>> If you don't actually want anything specific from the newer releases,
>>> it's just unnecessary churn.
>>>>>
>>>>> Wouldn't
e burden of having that many
> in-support
> > releases proves too heavy,
> > as you say we could reconsider.
> >
> > Andrew Schofield
> >
> > ----
> > > From: g...@confluent.io
> > > Date: Thu, 25 Aug 20
f the burden of having that many in-support
> releases proves too heavy,
> as you say we could reconsider.
>
> Andrew Schofield
>
>
> > From: g...@confluent.io
> > Date: Thu, 25 Aug 2016 09:57:30 -0700
> > Subject: Re: [DIS
pport
releases proves too heavy,
as you say we could reconsider.
Andrew Schofield
> From: g...@confluent.io
> Date: Thu, 25 Aug 2016 09:57:30 -0700
> Subject: Re: [DISCUSS] Time-based releases for Apache Kafka
> To: dev@kafka.apache.org
>
> I pre
knowledgeable about its innards.
>
> LTS works nicely for plenty of open-source projects. I think it would work
> well for Kafka too.
>
> Andrew Schofield
>
> ----------------
>> From: ofir.ma...@equalum.io
>> Date: Thu, 25 Aug 2016 16:07:07
ds.
LTS works nicely for plenty of open-source projects. I think it would work well
for Kafka too.
Andrew Schofield
> From: ofir.ma...@equalum.io
> Date: Thu, 25 Aug 2016 16:07:07 +0300
> Subject: Re: [DISCUSS] Time-based releases for Apache K
t major release, and removed in the major release
> > > after that.
> > >
> > > Because of the success of LTS models in this and other open source
> > > projects, I would suggest implementing a formal LTS plan for Kafka too.
> > >
> > > Regards,
> &
els in this and other open source
> > projects, I would suggest implementing a formal LTS plan for Kafka too.
> >
> > Regards,
> > --Vahid
> >
> >
> >
> > From: Gwen Shapira
> > To: dev@kafka.apache.org
> > Date: 08/09/2016 04:49 PM
> &g
or release
> after that.
>
> Because of the success of LTS models in this and other open source
> projects, I would suggest implementing a formal LTS plan for Kafka too.
>
> Regards,
> --Vahid
>
>
>
> From: Gwen Shapira
> To: dev@kafka.apache.org
> Da
in this and other open source
projects, I would suggest implementing a formal LTS plan for Kafka too.
Regards,
--Vahid
From: Gwen Shapira
To: dev@kafka.apache.org
Date: 08/09/2016 04:49 PM
Subject:[DISCUSS] Time-based releases for Apache Kafka
Dear Kafka Developers and Users
+1
Having better predictability when features will land is a huge benefit.
On Tue, Aug 16, 2016 at 5:34 PM, Jim Jagielski wrote:
> I'm following along on the thread so for sure! :)
>
>> On Aug 16, 2016, at 12:19 PM, Gwen Shapira wrote:
>>
>> Absolutely!
>>
>> If you have any concrete suggestion
I'm following along on the thread so for sure! :)
> On Aug 16, 2016, at 12:19 PM, Gwen Shapira wrote:
>
> Absolutely!
>
> If you have any concrete suggestions for steps we can take to improve
> the process, this will be most awesome. We'd love to learn from your
> long experience in Apache :)
>
Absolutely!
If you have any concrete suggestions for steps we can take to improve
the process, this will be most awesome. We'd love to learn from your
long experience in Apache :)
Gwen
On Tue, Aug 16, 2016 at 6:59 AM, Jim Jagielski wrote:
> By being aware of the potential issues, it's easier to
By being aware of the potential issues, it's easier to address
them at the start, and to create a process which does what
it can to "ensure" the problems don't pop up :)
> On Aug 16, 2016, at 9:48 AM, Ismael Juma wrote:
>
> Hi Jim,
>
> Thanks for your feedback. We value the community and we def
Hi Jim,
Thanks for your feedback. We value the community and we definitely want
Kafka to remain a fun and friendly place to participate. Under this
proposal, volunteers will still be able to do the work when they can. The
benefit is that it is likely to reach users faster since the next release
is
The idea of time-based releases make sense. The issue is
when they become the tail wagging the dog.
Recall that all developers and contributors are assumed to
be doing this because they are personally invested in the
project. Their is also the assumption that, as such, they
are volunteers and do t
Exactly :)
The goal is to have stable releases. We are hoping that time-based
will help achieve this goal as well as introduce some stability to the
planning process.
On Mon, Aug 15, 2016 at 12:55 PM, Nacho Solis
wrote:
> To clear up, I'm not against time-based releases, I just think that the
>
To clear up, I'm not against time-based releases, I just think that the
goals that were stated are not intrinsic to time-based releases but the
release process (whether it's time-based or not).
The goal of "when will my code get into a release" and the goal of getting
features faster in a release
I'm supportive of this for 2 reasons -
1. The community has been looking for predictability and this allows us to
offer that to Kafka users
2. Trunk stability and the ability to release from trunk. This is important
for several companies and more frequent releases means higher quality and
faster d
Plus one. This is a good direction to move towards.
The frequency of releases would probably depend on how long it takes
to certify the release.
> On Aug 13, 2016, at 10:18 AM, Jay Kreps wrote:
>
> I'm +1.
>
> I've seen this both ways and I really do think that time-based releases
> tend to sca
I'm +1.
I've seen this both ways and I really do think that time-based releases
tend to scale better with more developers doing parallel work (I think the
probability of at least one feature slipping as you have more and more
developers gets very high, and if that means the release slips then the
To add to what Gwen said (which makes sense to me), here's a link to the
Cassandra release model:
http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
It involves monthly releases, so more aggressive than what is being
proposed, but they follow a tick tock model where a feature relea
Thats good feedback, thanks.
I don't think you were involved in the previous release, but we did
try to follow the model you suggest.
We announced few weeks before cutting branches and gave time for
features and stabilization. This started a mad last-minute rush of
semi-baked features that forced
I'm not convinced that time-based releases for this type of development are
the right thing.
Something like Ubuntu, where all components are moving targets needs to
decide to freeze and release without having full coordination from the
participants. There is no guarantee from Canonical that the i
Interesting, so you are suggesting that we drop Kafka's current versioning
scheme (0.major.minor.patch)? I can see the reasoning for doing so now.
However, I think I'd prefer to do that when we do the 1.x bump, which I
think we should do once exactly-once lands. That way people only have to
re-lea
Right now, our major releases are really indicated in the second digit, not
in the leading 0. So 0.10 is a major, 0.10.1 is a minor and 0.10.0.1 is a
bug fix.
Thanks,
Jun
On Fri, Aug 12, 2016 at 1:17 PM, Gwen Shapira wrote:
> Good question!
>
> My thoughts are... bugfix releases will be done "
Good question!
My thoughts are... bugfix releases will be done "as needed" based on
community feedback
Feature releases will be a minor release by default 0.11, 0.12 - unless:
1. We manage to break compatibility completely (we shouldn't) in which
case we need to bump to 1.X
2. We do something tot
How would time releases relate to versions? (Major, minor, API
compatibility, etc).
On Thu, Aug 11, 2016 at 9:37 AM, Guozhang Wang wrote:
> I think we do not need to make the same guarantee as for "how old of your
> Kafka version that you can upgrade to the latest in one shot" (just call it
>
I think we do not need to make the same guarantee as for "how old of your
Kafka version that you can upgrade to the latest in one shot" (just call it
"upgrade maintenance" for short) and "how old of your Kafka version that
you can enjoy backport critical bug fixes from the latest version" (call it
Do we need to make a decision on this particular point? Could we gauge
community demand (people tend to ask for fixes to be backported in JIRA)
and decide then?
If we make a good job of avoiding regressions, then it seems that each
branch should really only need one or or a maximum of two bug fix
Hi Joel,
I think my suggestion was misunderstood. :) I suggested that we should
support upgrades to the latest release for a reasonable period (and I used
2 years as an example). That doesn't mean supporting all of those branches
for that period. It simply means that we maintain the code necessary
Yeah, I agree that maintaining 6 release branches is not really sustainable...
Maybe 3 (current and 2 older) makes sense?
On Wed, Aug 10, 2016 at 7:35 PM, Joel Koshy wrote:
> On Wed, Aug 10, 2016 at 5:44 PM, Joel Koshy wrote:
>
>>
>>
>> On Tue, Aug 9, 2016 at 4:49 PM, Gwen Shapira wrote:
>>
>>
Good question, let me clarify my thinking:
We were used to doing every year (or even at lower frequency). So the
expectation was that users will just upgrade once a year and we
wouldn't worry about backporting bugfixes to bugs that were over a
year old. It seemed pretty reasonable.
But if we are
On Wed, Aug 10, 2016 at 5:44 PM, Joel Koshy wrote:
>
>
> On Tue, Aug 9, 2016 at 4:49 PM, Gwen Shapira wrote:
>
>>
>> 4. Frequent releases mean we need to do bugfix releases for older
>> branches. Right now we only do bugfix releases to latest release.
>>
>
> I'm a bit unclear on how the above is
On Tue, Aug 9, 2016 at 4:49 PM, Gwen Shapira wrote:
>
> 4. Frequent releases mean we need to do bugfix releases for older
> branches. Right now we only do bugfix releases to latest release.
>
I'm a bit unclear on how the above is a side-effect of time-based releases.
IIUC this just changes how f
Hi Gwen,
Comments inline.
On Wed, Aug 10, 2016 at 6:21 PM, Gwen Shapira wrote:
> I hear what you are saying (enterprises upgrade every 2-years
> more-or-less). It seems reasonable - this basically means maintaining
> 10 compatibility tests at any point in time.
Indeed. Although it's up to 6 t
I hear what you are saying (enterprises upgrade every 2-years
more-or-less). It seems reasonable - this basically means maintaining
10 compatibility tests at any point in time. We will need to be
disciplined about maintaining those tests though - or it will get
painful.
Another thing, hurrying up
Hi Gwen,
The proposal sounds good to me. With regards to the cadence, 3 releases a
year (every 4 months as you said) sounds reasonable. One thing that I think
is very important if we release more often is that users should be able to
upgrade directly to the latest release for a reasonable period.
Dear Kafka Developers and Users,
In the past, our releases have been quite unpredictable. We'll notice
that a large number of nice features made it in (or are close),
someone would suggest a release and we'd do it. This is fun, but makes
planning really hard - we saw it during the last release whi
41 matches
Mail list logo
