Mailing-List: contact dev-help@airflow.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airflow.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CAHEEp7XdsQEwQbjraSbii+kXrDdjCP0kuF-fqpA6-TK9+eEqpQ@mail.gmail.com>
References: <8B669228-A1A6-44B1-B042-CB0ED87224E1@gmail.com>
 <CALCMntvXKdG8T2UjarQW=BO3rKq3_+gWYvuv7OFnM6wV4=OJgA@mail.gmail.com>
 <0C7ABEA9-9B9E-46ED-B9AA-C3F0BCAFE867@gmail.com> <CALCMntvupKrXdP+7mW5nJ0_LKSSu_-5t=rBjbVnc3vaxWqQnWA@mail.gmail.com>
 <CAFB79cpiRSrrROGUNPSd1Zrg8DBBE1Rj1xwBFZYTmGtDv-COng@mail.gmail.com> <CAHEEp7XdsQEwQbjraSbii+kXrDdjCP0kuF-fqpA6-TK9+eEqpQ@mail.gmail.com>
From: Chris Riccomini <criccomini@apache.org>
Date: Wed, 11 Jan 2017 10:51:17 -0800
Message-ID: <CABYbY7cXa+FPMDsSCM9DLrbHFGRBvBptMjQJkKS3GUEVquC4rQ@mail.gmail.com>
Subject: Re: Airflow Release Planning and Supported Release Lifetime
To: dev@airflow.incubator.apache.org
Content-Type: multipart/alternative; boundary=94eb2c05e9160318440545d61606
archived-at: Wed, 11 Jan 2017 18:51:25 -0000

--94eb2c05e9160318440545d61606
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey Bolke,

This sounds great to me. +1 A quick blurb on the wiki about versioning
(e.g. 1.8.0a3 vs 1.8.0, vs however the RC is going to be versioned) should
be called out, too.

Re: a vote, I'd say it's a good idea, regardless of whether its required or
not, just to make sure everyone's on the same page.

Cheers,
Chris

On Mon, Jan 9, 2017 at 6:03 PM, Maxime Beauchemin <
maximebeauchemin@gmail.com> wrote:

> 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 basicall=
y
> > 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=E2=80=9D (
> > > > >>
> > > > 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=E2=80=99s Release Planning for thi=
s, 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 (=E2=80=9Cmaintenance mode=E2=80=9D) N-1. So i=
f 1.9.0 is
> released,
> > > > 1.8.X
> > > > >> enters maintenance. 1.7.X is EOL=E2=80=99d.
> > > > >> * Patches to closed branches (ie. RC+) need to have a signoff fr=
om
> > > > 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 =E2=80=9CvX.Y-test=E2=80=9D and =E2=
=80=9CvX.Y-stable=E2=80=9D. No
> minor
> > > > >> branches. Thus when 1.8.0 is released, this will be the stable
> > branch
> > > > >> =E2=80=9Cv1.8-stable=E2=80=9D, automatically =E2=80=9Cv1.8-test=
=E2=80=9D 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
> > >
> >
>

--94eb2c05e9160318440545d61606--