airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxime Beauchemin <maximebeauche...@gmail.com>
Subject Re: Airflow Release Planning and Supported Release Lifetime
Date Tue, 10 Jan 2017 02:03:39 GMT
All of this looks very reasonable to me. I'm hoping we can get close to
monthly dot-releases as we find our cadence to distribute the "stress of
releasing" more uniformly over time.

Max

On Mon, Jan 9, 2017 at 10:39 AM, Chris Nauroth <cnauroth@apache.org> wrote:

> I'm not aware of any strict rule that a release manager must be a
> committer.  However, the activities of a product release almost always
> involve things like tagging the source repository, so in practice, I've
> always seen that the release manager is a committer on the project.
>
>
> Chris Nauroth
>
> On Sun, Jan 8, 2017 at 10:48 AM, Alex Van Boxel <alex@vanboxel.be> wrote:
>
> > Thanks for clarifying (I'm new to this Apache releasing ;-)
> >
> > On Sun, Jan 8, 2017 at 6:58 PM Bolke de Bruin <bdbruin@gmail.com> wrote:
> >
> > > This would be for changes AFTER release / rc. Ie. an RC is basically
> what
> > > we as a community deem stable and under normal circumstances is the
> equal
> > > to the release. A release is done by a release manager (per Apache
> > > guidelines) so it makes sense that a release manager can only apply
> > patches
> > > to a release. For this release I am the release manager.
> > >
> > > Alpha and beta versions are open to any committer.
> > >
> > > That's the idea which to me makes sense, but maybe an other option is
> > > better?
> > >
> > > Bolke
> > >
> > >
> > > Sent from my iPhone
> > >
> > > > On 8 Jan 2017, at 18:27, Alex Van Boxel <alex@vanboxel.be> wrote:
> > > >
> > > > This looks good, except do we need a release manager that applies
> > > patches?
> > > >
> > > >> On Sun, Jan 8, 2017, 14:36 Bolke de Bruin <bdbruin@gmail.com>
> wrote:
> > > >>
> > > >> Hi All,
> > > >>
> > > >> As part of the release process I have created "Airflow Release
> > Planning
> > > >> and Supported Release Lifetime” (
> > > >>
> > > https://cwiki.apache.org/confluence/display/AIRFLOW/
> > Airflow+Release+Planning+and+Supported+Release+Lifetime
> > > >> <
> > > >>
> > > https://cwiki.apache.org/confluence/display/AIRFLOW/
> > Airflow+Release+Planning+and+Supported+Release+Lifetime
> > > >).
> > > >> I borrowed heavily from Samba’s Release Planning for this, so any
> > > >> resemblance is not coincidental :-).
> > > >>
> > > >> Please take a look and make suggestions as not all may fit our
> rhythm.
> > > >> Main take aways:
> > > >>
> > > >> * We aim to do a major release every 6 months (ie. 1.8 -> 1.9)
> > > >> * Minor releases (1.8.0 -> 1.8.1) can happen whenever needed.
> > > >> * We only support (“maintenance mode”) N-1. So if 1.9.0 is released,
> > > 1.8.X
> > > >> enters maintenance. 1.7.X is EOL’d.
> > > >> * Patches to closed branches (ie. RC+) need to have a signoff from
> > > another
> > > >> committer and support from the mailinglist (Can this be done in the
> > > Apache
> > > >> way?). A release manager then needs to apply te patch.
> > > >>
> > > >> Other:
> > > >> * Patches land on master first
> > > >> * Branches are maintained as “vX.Y-test” and “vX.Y-stable”.
No minor
> > > >> branches. Thus when 1.8.0 is released, this will be the stable
> branch
> > > >> “v1.8-stable”, automatically “v1.8-test” becomes the to be
1.8.1
> > > version.
> > > >>
> > > >> I hope this makes sense. Do we need to vote on this?
> > > >>
> > > >> Cheers
> > > >> Bolke
> > > >>
> > > >>
> > >
> > --
> >   _/
> > _/ Alex Van Boxel
> >
>

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