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 <[email protected]> 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 <[email protected]> wrote: > > > Thanks for clarifying (I'm new to this Apache releasing ;-) > > > > On Sun, Jan 8, 2017 at 6:58 PM Bolke de Bruin <[email protected]> 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 <[email protected]> wrote: > > > > > > > > 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 > > > >> > > > >> > > > > > -- > > _/ > > _/ Alex Van Boxel > > >
