kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nacho Solis <nso...@linkedin.com.INVALID>
Subject Re: [DISCUSS] Time-based releases for Apache Kafka
Date Fri, 12 Aug 2016 21:35:31 GMT
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 intermediate
product works well together.   Debian takes a different (and more stable)
approach and releases on features.  They also have to corral a bunch of
separate components and make them work together.

I would argue that the benefit of a release is that it's tested and
coherent. From a kafka standpoint I would rather see releases on
feature[set] with some testing and then have some notion of bug support for
a little while.  If I want to have cutting edge or more frequent releases
then I should be able to grab stuff off of github and run that.


I don't agree that the benefits we're looking for are what we're going to
get.

We can achieve some of the benefits listed without having to have timed
releases.  What it seems you're looking for is more of a "heads up"
announcement that we plan to do a release.  We could have a release process
that gives 4 weeks of warning.  2 weeks to get features in, 2 weeks of
freeze and then a release.  There is no need to fix how often (and when)
this process happens.  We just know that for a release to happen we'll have
4 weeks advance notice.

Nacho



On Fri, Aug 12, 2016 at 1:17 PM, Gwen Shapira <gwen@confluent.io> wrote:

> 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 totally amazing (exactly once?) and decide to bump
> to 1.X to celebrate
> 3. The release manager decides that the features in the release are
> not very exciting and we can go with 0.10.1 (i.e very minor release)
>
> Does that make sense?
>
> On Fri, Aug 12, 2016 at 10:25 AM, Nacho Solis
> <nsolis@linkedin.com.invalid> wrote:
> > How would time releases relate to versions? (Major, minor, API
> > compatibility, etc).
> >
> > On Thu, Aug 11, 2016 at 9:37 AM, Guozhang Wang <wangguoz@gmail.com>
> 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
> >> "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
> >> "bugfix backport maintenance" for short).
> >>
> >> Upgrade maintenance: I think 2 years is a good cadence, and we can use
> the
> >> same policy for getting rid of obsolete APIs / protocols as well. I.e.
> say
> >> we release 0.10.1.0 in 2017FEB then we can in that release drop
> obsoleted
> >> code in 0.8.2 (released in 2015FEB), such that users cannot directly
> >> upgrade from 0.8.2.x to 0.10.1.x, but needs to have another hop.
> >>
> >> Bugfix backports maintenance: if we release every 4 months, then
> current +
> >> 2 older means we have one year period for back-port critical bug fixes,
> >> which sounds good to me; if we release every 3 months, then probably we
> >> should have current + 3 older.
> >>
> >>
> >> Guozhang
> >>
> >>
> >> On Thu, Aug 11, 2016 at 12:14 AM, Ismael Juma <ismael@juma.me.uk>
> wrote:
> >>
> >> > 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
> >> releases.
> >> > After that, users are welcome to upgrade to a new feature release (and
> >> > hopefully to the most current) to get non-critical fixes and
> features. An
> >> > exception is if we get security fixes. We probably do need a policy
> for
> >> how
> >> > far we backport those.
> >> >
> >> > Ismael
> >> >
> >> > On Thu, Aug 11, 2016 at 4:35 AM, Gwen Shapira <gwen@confluent.io>
> wrote:
> >> >
> >> > > 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 <jjkoshy.w@gmail.com>
> >> wrote:
> >> > > > On Wed, Aug 10, 2016 at 5:44 PM, Joel Koshy <jjkoshy.w@gmail.com>
> >> > wrote:
> >> > > >
> >> > > >>
> >> > > >>
> >> > > >> On Tue, Aug 9, 2016 at 4:49 PM, Gwen Shapira <gwen@confluent.io>
> >> > 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 frequently we release
off
> the
> >> > > current
> >> > > >> release branch right? Or put another way, are you also proposing
> any
> >> > > >> fundamental change to our versioning/branching scheme?
> >> > > >>
> >> > > >
> >> > > > Actually nm - so what you're saying is we cut more frequently
off
> >> trunk
> >> > > > which means having to maintaining multiple release branches.
> However,
> >> > the
> >> > > > more frequently we release then it should be less difficult to
> >> upgrade
> >> > > from
> >> > > > one release to another which means it should be reasonable to
> expect
> >> > that
> >> > > > we EOL release branches sooner than later.
> >> > > >
> >> > > > However, if we are expected to maintain release branches for
up to
> >> two
> >> > > > years then that means potential bugfix releases for up to eight
> >> release
> >> > > > branches at any given time? i.e., it seems that a short
> inter-release
> >> > > > interval would require us to EOL release branches sooner than
> that to
> >> > > make
> >> > > > things manageable.
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Gwen Shapira
> >> > > Product Manager | Confluent
> >> > > 650.450.2760 | @gwenshap
> >> > > Follow us: Twitter | blog
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> -- Guozhang
> >>
> >
> >
> >
> > --
> > Nacho (Ignacio) Solis
> > nsolis@linkedin.com
>
>
>
> --
> Gwen Shapira
> Product Manager | Confluent
> 650.450.2760 | @gwenshap
> Follow us: Twitter | blog
>



-- 
Nacho (Ignacio) Solis
nsolis@linkedin.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message