You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Bolke de Bruin <bd...@gmail.com> on 2017/01/08 13:36:49 UTC
Airflow Release Planning and Supported Release Lifetime
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
Re: Airflow Release Planning and Supported Release Lifetime
Posted by Chris Riccomini <cr...@apache.org>.
Hey Bolke,
This sounds great to me. +1 A quick blurb on the wiki about versioning
(e.g. 1.8.0a3 vs 1.8.0, vs however the RC is going to be versioned) should
be called out, too.
Re: a vote, I'd say it's a good idea, regardless of whether its required or
not, just to make sure everyone's on the same page.
Cheers,
Chris
On Mon, Jan 9, 2017 at 6:03 PM, Maxime Beauchemin <
maximebeauchemin@gmail.com> wrote:
> 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 <cn...@apache.org>
> 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 <al...@vanboxel.be>
> wrote:
> >
> > > Thanks for clarifying (I'm new to this Apache releasing ;-)
> > >
> > > On Sun, Jan 8, 2017 at 6:58 PM Bolke de Bruin <bd...@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 <al...@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 <bd...@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
> > >
> >
>
Re: Airflow Release Planning and Supported Release Lifetime
Posted by Maxime Beauchemin <ma...@gmail.com>.
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 <cn...@apache.org> 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 <al...@vanboxel.be> wrote:
>
> > Thanks for clarifying (I'm new to this Apache releasing ;-)
> >
> > On Sun, Jan 8, 2017 at 6:58 PM Bolke de Bruin <bd...@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 <al...@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 <bd...@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
> >
>
Re: Airflow Release Planning and Supported Release Lifetime
Posted by Chris Nauroth <cn...@apache.org>.
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 <al...@vanboxel.be> wrote:
> Thanks for clarifying (I'm new to this Apache releasing ;-)
>
> On Sun, Jan 8, 2017 at 6:58 PM Bolke de Bruin <bd...@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 <al...@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 <bd...@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
>
Re: Airflow Release Planning and Supported Release Lifetime
Posted by Alex Van Boxel <al...@vanboxel.be>.
Thanks for clarifying (I'm new to this Apache releasing ;-)
On Sun, Jan 8, 2017 at 6:58 PM Bolke de Bruin <bd...@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 <al...@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 <bd...@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
Re: Airflow Release Planning and Supported Release Lifetime
Posted by Bolke de Bruin <bd...@gmail.com>.
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 <al...@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 <bd...@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
>>
>>
Re: Airflow Release Planning and Supported Release Lifetime
Posted by Alex Van Boxel <al...@vanboxel.be>.
This looks good, except do we need a release manager that applies patches?
On Sun, Jan 8, 2017, 14:36 Bolke de Bruin <bd...@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
>
>