airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Van Boxel <a...@vanboxel.be>
Subject Re: Airflow Release Planning and Supported Release Lifetime
Date Sun, 08 Jan 2017 18:48:49 GMT
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