airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bolke de Bruin <bdbr...@gmail.com>
Subject Re: Airflow Release Planning and Supported Release Lifetime
Date Sun, 08 Jan 2017 17:58:29 GMT
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
>> 
>> 

Mime
View raw message