This looks good, except do we need a release manager that applies patches? On Sun, Jan 8, 2017, 14:36 Bolke de Bruin <[email protected]> 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 > >
