You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Ash Berlin-Taylor <as...@apache.org> on 2020/02/07 13:05:32 UTC
Shorter release vote or 1.10.9 to pin Werkzeug dep
Hello all,
So Werkzeug 1.0 was released this morning, and it finally broke a number of direct or indirect dependencies of ours (Werkzeug is a WSGI helper library. It mans "tool" in German.) -- meaning 1.10.8 that was just released won't funciton
(The fix for now is to do pip install "werkzeug<1.0.0")
So I'm going to release 1.10.9 with the fix from Jarek to pin the version (yes, pinning properly is something we still need to tackle.) and I would like to not wait for 72 hours for this release.
It appears that 72 hours is just a convention, see https://apache.org/legal/release-policy.html#release-approval:
> Release votes SHOULD remain open for at least 72 hours.
In this case since the change (https://github.com/apache/airflow/pull/7377) is one line to restrict the version of Werkzeug to the known working version that passed the 1.10.8 vote I am propsing that in case I have the following vote:
For 72 hours _OR_ until 3 binding votes have been cast
(Normally the vote is and.) What do people thing?
-ash
Re: Shorter release vote or 1.10.9 to pin Werkzeug dep
Posted by Jarek Potiuk <Ja...@polidea.com>.
Yep we will release 1.10.10 once it's solved :).
czw., 13 lut 2020, 00:24 użytkownik Ash Berlin-Taylor <as...@apache.org>
napisał:
> Yes, pinning Werkzeug was only a temporary fix until all the transitive
> dependency versions are correctly updates, for instance Flask-AppBuilder
> has merged the fix
> https://github.com/dpgaspar/Flask-AppBuilder/commit/7a9c2b822265fc9194ea038798814a06b10ccdb2
> but that is not yet included in any release.
>
> On Feb 12 2020, at 11:01 pm, Anton Zayniev <an...@gmail.com>
> wrote:
> > I'm not sure this is a correct thread, but IMO pinning werkzeug version
> is
> > a little bit too strong. We may have a problem if one dependencies will
> use
> > some functionality of werkzeug>1.0. Afaik flask currently allows
> > werkzeug>1.0 usage, that'll probably introduce some discrepancies soon.
> > Meanwhile I discovered that the only library that introduces problem for
> > now is flask-admin. And it is already patched
> > <https://github.com/flask-admin/flask-admin/releases/tag/v1.5.5> to fix
> > conflict. I think that just bumping flask-admin to 1.5.5 (currently
> 1.5.4)
> > would be more accurate fix.
> > Anton
> >
> > On Fri, 7 Feb 2020 at 16:06, Kaxil Naik <ka...@gmail.com> wrote:
> > > +1 binding
> > > On Fri, Feb 7, 2020, 20:41 Daniel Imberman <da...@gmail.com>
> > > wrote:
> > >
> > > > +1 binding
> > > > via Newton Mail
> > > > [
> > > >
> > >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.6&source=email_footer_2
> > > > ]
> > > > On Fri, Feb 7, 2020 at 6:22 AM, Bolke de Bruin <bd...@gmail.com>
> > >
> > > wrote:
> > > > +1 binding
> > > >
> > > > Sent from my iPhone
> > > > > On 7 Feb 2020, at 14:08, Jarek Potiuk <Ja...@polidea.com>
> > > wrote:
> > > > >
> > > > > Agree.
> > > > > > On Fri, Feb 7, 2020 at 2:05 PM Ash Berlin-Taylor <ash@apache.org
> >
> > > > wrote:
> > > > > >
> > > > > > Hello all,
> > > > > > So Werkzeug 1.0 was released this morning, and it finally broke a
> > > > number
> > > > > > of direct or indirect dependencies of ours (Werkzeug is a WSGI
> helper
> > > > > > library. It mans "tool" in German.) -- meaning 1.10.8 that was
> just
> > > > > > released won't funciton
> > > > > > (The fix for now is to do pip install "werkzeug<1.0.0")
> > > > > > So I'm going to release 1.10.9 with the fix from Jarek to pin the
> > > > >
> > > >
> > > > version
> > > > > > (yes, pinning properly is something we still need to tackle.)
> and I
> > > > >
> > > >
> > > > would
> > > > > > like to not wait for 72 hours for this release.
> > > > > > It appears that 72 hours is just a convention, see
> > > > > > https://apache.org/legal/release-policy.html#release-approval:
> > > > > > > Release votes SHOULD remain open for at least 72 hours.
> > > > > >
> > > > > > In this case since the change
> > > > >
> > > >
> > > > (https://github.com/apache/airflow/pull/7377)
> > > > > > is one line to restrict the version of Werkzeug to the known
> working
> > > > > > version that passed the 1.10.8 vote I am propsing that in case I
> have
> > > > >
> > > >
> > > > the
> > > > > > following vote:
> > > > > > For 72 hours _OR_ until 3 binding votes have been cast
> > > > > > (Normally the vote is and.) What do people thing?
> > > > > > -ash
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jarek Potiuk
> > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > > >
> > > > > M: +48 660 796 129 <+48660796129>
> > > > > [image: Polidea] <https://www.polidea.com/>
> > > >
> > >
> >
> >
>
>
Re: Shorter release vote or 1.10.9 to pin Werkzeug dep
Posted by Ash Berlin-Taylor <as...@apache.org>.
Yes, pinning Werkzeug was only a temporary fix until all the transitive dependency versions are correctly updates, for instance Flask-AppBuilder has merged the fix https://github.com/dpgaspar/Flask-AppBuilder/commit/7a9c2b822265fc9194ea038798814a06b10ccdb2 but that is not yet included in any release.
On Feb 12 2020, at 11:01 pm, Anton Zayniev <an...@gmail.com> wrote:
> I'm not sure this is a correct thread, but IMO pinning werkzeug version is
> a little bit too strong. We may have a problem if one dependencies will use
> some functionality of werkzeug>1.0. Afaik flask currently allows
> werkzeug>1.0 usage, that'll probably introduce some discrepancies soon.
> Meanwhile I discovered that the only library that introduces problem for
> now is flask-admin. And it is already patched
> <https://github.com/flask-admin/flask-admin/releases/tag/v1.5.5> to fix
> conflict. I think that just bumping flask-admin to 1.5.5 (currently 1.5.4)
> would be more accurate fix.
> Anton
>
> On Fri, 7 Feb 2020 at 16:06, Kaxil Naik <ka...@gmail.com> wrote:
> > +1 binding
> > On Fri, Feb 7, 2020, 20:41 Daniel Imberman <da...@gmail.com>
> > wrote:
> >
> > > +1 binding
> > > via Newton Mail
> > > [
> > >
> > https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.6&source=email_footer_2
> > > ]
> > > On Fri, Feb 7, 2020 at 6:22 AM, Bolke de Bruin <bd...@gmail.com>
> >
> > wrote:
> > > +1 binding
> > >
> > > Sent from my iPhone
> > > > On 7 Feb 2020, at 14:08, Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> > > >
> > > > Agree.
> > > > > On Fri, Feb 7, 2020 at 2:05 PM Ash Berlin-Taylor <as...@apache.org>
> > > wrote:
> > > > >
> > > > > Hello all,
> > > > > So Werkzeug 1.0 was released this morning, and it finally broke a
> > > number
> > > > > of direct or indirect dependencies of ours (Werkzeug is a WSGI helper
> > > > > library. It mans "tool" in German.) -- meaning 1.10.8 that was just
> > > > > released won't funciton
> > > > > (The fix for now is to do pip install "werkzeug<1.0.0")
> > > > > So I'm going to release 1.10.9 with the fix from Jarek to pin the
> > > >
> > >
> > > version
> > > > > (yes, pinning properly is something we still need to tackle.) and I
> > > >
> > >
> > > would
> > > > > like to not wait for 72 hours for this release.
> > > > > It appears that 72 hours is just a convention, see
> > > > > https://apache.org/legal/release-policy.html#release-approval:
> > > > > > Release votes SHOULD remain open for at least 72 hours.
> > > > >
> > > > > In this case since the change
> > > >
> > >
> > > (https://github.com/apache/airflow/pull/7377)
> > > > > is one line to restrict the version of Werkzeug to the known working
> > > > > version that passed the 1.10.8 vote I am propsing that in case I have
> > > >
> > >
> > > the
> > > > > following vote:
> > > > > For 72 hours _OR_ until 3 binding votes have been cast
> > > > > (Normally the vote is and.) What do people thing?
> > > > > -ash
> > > > >
> > > >
> > > >
> > > > --
> > > > Jarek Potiuk
> > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >
> > > > M: +48 660 796 129 <+48660796129>
> > > > [image: Polidea] <https://www.polidea.com/>
> > >
> >
>
>
Re: Shorter release vote or 1.10.9 to pin Werkzeug dep
Posted by Anton Zayniev <an...@gmail.com>.
I'm not sure this is a correct thread, but IMO pinning werkzeug version is
a little bit too strong. We may have a problem if one dependencies will use
some functionality of werkzeug>1.0. Afaik flask currently allows
werkzeug>1.0 usage, that'll probably introduce some discrepancies soon.
Meanwhile I discovered that the only library that introduces problem for
now is flask-admin. And it is already patched
<https://github.com/flask-admin/flask-admin/releases/tag/v1.5.5> to fix
conflict. I think that just bumping flask-admin to 1.5.5 (currently 1.5.4)
would be more accurate fix.
Anton
On Fri, 7 Feb 2020 at 16:06, Kaxil Naik <ka...@gmail.com> wrote:
> +1 binding
>
> On Fri, Feb 7, 2020, 20:41 Daniel Imberman <da...@gmail.com>
> wrote:
>
> > +1 binding
> > via Newton Mail
> > [
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.6&source=email_footer_2
> > ]
> > On Fri, Feb 7, 2020 at 6:22 AM, Bolke de Bruin <bd...@gmail.com>
> wrote:
> > +1 binding
> >
> > Sent from my iPhone
> >
> > > On 7 Feb 2020, at 14:08, Jarek Potiuk <Ja...@polidea.com>
> wrote:
> > >
> > > Agree.
> > >
> > >> On Fri, Feb 7, 2020 at 2:05 PM Ash Berlin-Taylor <as...@apache.org>
> > wrote:
> > >>
> > >> Hello all,
> > >>
> > >> So Werkzeug 1.0 was released this morning, and it finally broke a
> > number
> > >> of direct or indirect dependencies of ours (Werkzeug is a WSGI helper
> > >> library. It mans "tool" in German.) -- meaning 1.10.8 that was just
> > >> released won't funciton
> > >> (The fix for now is to do pip install "werkzeug<1.0.0")
> > >> So I'm going to release 1.10.9 with the fix from Jarek to pin the
> > version
> > >> (yes, pinning properly is something we still need to tackle.) and I
> > would
> > >> like to not wait for 72 hours for this release.
> > >> It appears that 72 hours is just a convention, see
> > >> https://apache.org/legal/release-policy.html#release-approval:
> > >>> Release votes SHOULD remain open for at least 72 hours.
> > >> In this case since the change
> > (https://github.com/apache/airflow/pull/7377)
> > >> is one line to restrict the version of Werkzeug to the known working
> > >> version that passed the 1.10.8 vote I am propsing that in case I have
> > the
> > >> following vote:
> > >> For 72 hours _OR_ until 3 binding votes have been cast
> > >> (Normally the vote is and.) What do people thing?
> > >> -ash
> > >>
> > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48660796129>
> > > [image: Polidea] <https://www.polidea.com/>
>
Re: Shorter release vote or 1.10.9 to pin Werkzeug dep
Posted by Kaxil Naik <ka...@gmail.com>.
+1 binding
On Fri, Feb 7, 2020, 20:41 Daniel Imberman <da...@gmail.com>
wrote:
> +1 binding
> via Newton Mail
> [
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.6&source=email_footer_2
> ]
> On Fri, Feb 7, 2020 at 6:22 AM, Bolke de Bruin <bd...@gmail.com> wrote:
> +1 binding
>
> Sent from my iPhone
>
> > On 7 Feb 2020, at 14:08, Jarek Potiuk <Ja...@polidea.com> wrote:
> >
> > Agree.
> >
> >> On Fri, Feb 7, 2020 at 2:05 PM Ash Berlin-Taylor <as...@apache.org>
> wrote:
> >>
> >> Hello all,
> >>
> >> So Werkzeug 1.0 was released this morning, and it finally broke a
> number
> >> of direct or indirect dependencies of ours (Werkzeug is a WSGI helper
> >> library. It mans "tool" in German.) -- meaning 1.10.8 that was just
> >> released won't funciton
> >> (The fix for now is to do pip install "werkzeug<1.0.0")
> >> So I'm going to release 1.10.9 with the fix from Jarek to pin the
> version
> >> (yes, pinning properly is something we still need to tackle.) and I
> would
> >> like to not wait for 72 hours for this release.
> >> It appears that 72 hours is just a convention, see
> >> https://apache.org/legal/release-policy.html#release-approval:
> >>> Release votes SHOULD remain open for at least 72 hours.
> >> In this case since the change
> (https://github.com/apache/airflow/pull/7377)
> >> is one line to restrict the version of Werkzeug to the known working
> >> version that passed the 1.10.8 vote I am propsing that in case I have
> the
> >> following vote:
> >> For 72 hours _OR_ until 3 binding votes have been cast
> >> (Normally the vote is and.) What do people thing?
> >> -ash
> >>
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
Re: Shorter release vote or 1.10.9 to pin Werkzeug dep
Posted by Daniel Imberman <da...@gmail.com>.
+1 binding
via Newton Mail
[https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.6&source=email_footer_2]
On Fri, Feb 7, 2020 at 6:22 AM, Bolke de Bruin <bd...@gmail.com> wrote:
+1 binding
Sent from my iPhone
> On 7 Feb 2020, at 14:08, Jarek Potiuk <Ja...@polidea.com> wrote:
>
> Agree.
>
>> On Fri, Feb 7, 2020 at 2:05 PM Ash Berlin-Taylor <as...@apache.org>
wrote:
>>
>> Hello all,
>>
>> So Werkzeug 1.0 was released this morning, and it finally broke a
number
>> of direct or indirect dependencies of ours (Werkzeug is a WSGI helper
>> library. It mans "tool" in German.) -- meaning 1.10.8 that was just
>> released won't funciton
>> (The fix for now is to do pip install "werkzeug<1.0.0")
>> So I'm going to release 1.10.9 with the fix from Jarek to pin the
version
>> (yes, pinning properly is something we still need to tackle.) and I
would
>> like to not wait for 72 hours for this release.
>> It appears that 72 hours is just a convention, see
>> https://apache.org/legal/release-policy.html#release-approval:
>>> Release votes SHOULD remain open for at least 72 hours.
>> In this case since the change
(https://github.com/apache/airflow/pull/7377)
>> is one line to restrict the version of Werkzeug to the known working
>> version that passed the 1.10.8 vote I am propsing that in case I have
the
>> following vote:
>> For 72 hours _OR_ until 3 binding votes have been cast
>> (Normally the vote is and.) What do people thing?
>> -ash
>>
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
Re: Shorter release vote or 1.10.9 to pin Werkzeug dep
Posted by Bolke de Bruin <bd...@gmail.com>.
+1 binding
Sent from my iPhone
> On 7 Feb 2020, at 14:08, Jarek Potiuk <Ja...@polidea.com> wrote:
>
> Agree.
>
>> On Fri, Feb 7, 2020 at 2:05 PM Ash Berlin-Taylor <as...@apache.org> wrote:
>>
>> Hello all,
>>
>> So Werkzeug 1.0 was released this morning, and it finally broke a number
>> of direct or indirect dependencies of ours (Werkzeug is a WSGI helper
>> library. It mans "tool" in German.) -- meaning 1.10.8 that was just
>> released won't funciton
>> (The fix for now is to do pip install "werkzeug<1.0.0")
>> So I'm going to release 1.10.9 with the fix from Jarek to pin the version
>> (yes, pinning properly is something we still need to tackle.) and I would
>> like to not wait for 72 hours for this release.
>> It appears that 72 hours is just a convention, see
>> https://apache.org/legal/release-policy.html#release-approval:
>>> Release votes SHOULD remain open for at least 72 hours.
>> In this case since the change (https://github.com/apache/airflow/pull/7377)
>> is one line to restrict the version of Werkzeug to the known working
>> version that passed the 1.10.8 vote I am propsing that in case I have the
>> following vote:
>> For 72 hours _OR_ until 3 binding votes have been cast
>> (Normally the vote is and.) What do people thing?
>> -ash
>>
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
Re: Shorter release vote or 1.10.9 to pin Werkzeug dep
Posted by Jarek Potiuk <Ja...@polidea.com>.
Agree.
On Fri, Feb 7, 2020 at 2:05 PM Ash Berlin-Taylor <as...@apache.org> wrote:
> Hello all,
>
> So Werkzeug 1.0 was released this morning, and it finally broke a number
> of direct or indirect dependencies of ours (Werkzeug is a WSGI helper
> library. It mans "tool" in German.) -- meaning 1.10.8 that was just
> released won't funciton
> (The fix for now is to do pip install "werkzeug<1.0.0")
> So I'm going to release 1.10.9 with the fix from Jarek to pin the version
> (yes, pinning properly is something we still need to tackle.) and I would
> like to not wait for 72 hours for this release.
> It appears that 72 hours is just a convention, see
> https://apache.org/legal/release-policy.html#release-approval:
> > Release votes SHOULD remain open for at least 72 hours.
> In this case since the change (https://github.com/apache/airflow/pull/7377)
> is one line to restrict the version of Werkzeug to the known working
> version that passed the 1.10.8 vote I am propsing that in case I have the
> following vote:
> For 72 hours _OR_ until 3 binding votes have been cast
> (Normally the vote is and.) What do people thing?
> -ash
>
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
Re: Shorter release vote or 1.10.9 to pin Werkzeug dep
Posted by "Driesprong, Fokko" <fo...@driesprong.frl>.
Hi Ash,
I'm fine with doing a quicker release, as long as we have 3 PMC votes
(preferably more).
Cheers, Fokko
Op vr 7 feb. 2020 om 14:05 schreef Ash Berlin-Taylor <as...@apache.org>:
> Hello all,
>
> So Werkzeug 1.0 was released this morning, and it finally broke a number
> of direct or indirect dependencies of ours (Werkzeug is a WSGI helper
> library. It mans "tool" in German.) -- meaning 1.10.8 that was just
> released won't funciton
> (The fix for now is to do pip install "werkzeug<1.0.0")
> So I'm going to release 1.10.9 with the fix from Jarek to pin the version
> (yes, pinning properly is something we still need to tackle.) and I would
> like to not wait for 72 hours for this release.
> It appears that 72 hours is just a convention, see
> https://apache.org/legal/release-policy.html#release-approval:
> > Release votes SHOULD remain open for at least 72 hours.
> In this case since the change (https://github.com/apache/airflow/pull/7377)
> is one line to restrict the version of Werkzeug to the known working
> version that passed the 1.10.8 vote I am propsing that in case I have the
> following vote:
> For 72 hours _OR_ until 3 binding votes have been cast
> (Normally the vote is and.) What do people thing?
> -ash
>
Re: Shorter release vote or 1.10.9 to pin Werkzeug dep
Posted by Deng Xiaodong <xd...@gmail.com>.
I agree with what Ash is proposing, and would like to give my +1.
Thanks.
XD
> On 7 Feb 2020, at 2:05 PM, Ash Berlin-Taylor <as...@apache.org> wrote:
>
> Hello all,
>
> So Werkzeug 1.0 was released this morning, and it finally broke a number of direct or indirect dependencies of ours (Werkzeug is a WSGI helper library. It mans "tool" in German.) -- meaning 1.10.8 that was just released won't funciton
> (The fix for now is to do pip install "werkzeug<1.0.0")
> So I'm going to release 1.10.9 with the fix from Jarek to pin the version (yes, pinning properly is something we still need to tackle.) and I would like to not wait for 72 hours for this release.
> It appears that 72 hours is just a convention, see https://apache.org/legal/release-policy.html#release-approval:
>> Release votes SHOULD remain open for at least 72 hours.
> In this case since the change (https://github.com/apache/airflow/pull/7377) is one line to restrict the version of Werkzeug to the known working version that passed the 1.10.8 vote I am propsing that in case I have the following vote:
> For 72 hours _OR_ until 3 binding votes have been cast
> (Normally the vote is and.) What do people thing?
> -ash