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
