> Is there a particular timeline we need to hit in order to make your next provider release?
Airflow providers are released every 2 weeks These are the planned dates https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=399278789#ReleasePlan-ProviderReleases On Mon, Jul 27, 2026 at 4:10 PM Danny McCormick via dev < [email protected]> wrote: > Thanks for following up on this! > > > Can we count on ~ beginning of August release of 2.76.0 of python beam > client? > > Yes, we should be releasing in early August as you noted. Is there a > particular timeline we need to hit in order to make your next provider > release? > > Thanks, > Danny > > On Mon, Jul 27, 2026 at 7:05 AM Jarek Potiuk <[email protected]> wrote: > > > Hi Beam devs, > > > > Writing from the Apache Airflow side with a short status note and one > > question about 2.76.0 timing. > > > > Can we count on ~ beginning of August release of 2.76.0 of python beam > > client? > > > > Background: Airflow suspended its apache-beam provider earlier this year > > [1]. We have a PR open to restore it [2] (tracking issue [3]), and at > this > > point the only thing still blocking us is dependency resolution. > > > > Every released Beam up to and including 2.75.0 declares: > > > > envoy-data-plane<2,>=1.0.3; python_version >= "3.11" > > > > The only release in that range is envoy-data-plane 1.0.3, which pins > > betterproto==2.0.0b6. betterproto has never shipped a final 2.x - its > > latest stable is 1.2.5, from 2020 - so that pin is only ever satisfiable > > by a pre-release. Resolvers that do not opt into pre-releases for > > transitive dependencies reject it outright. > > > > The good news is that your team already fixed this in main. > > The [4] removed envoy-data-plane and the > > transitive betterproto from the Python SDK entirely, replacing them with > a > > small vendored Envoy RLS proto, and CHANGES.md lists it under 2.76.0. It > > merged on 2026-07-07, one day after the 2.75.0 branch cut, so it just > > missed that release. > > > > So from our checks, a released 2.76.0 is the last thing standing between > us > > and un-suspending the provider. Once we can floor the provider at > > apache-beam>=2.76.0, the problem disappears on every Python version we > > support and we need no workaround on our side. Until then our options are > > to wait, or to carry a local pre-release constraint that we would rather > > not ship. > > > > Hence the question: is the 2.76.0 branch cut still on for 5 August, per > the > > release calendar [5]? Nothing urgent, and no ask to change anything - we > > just want to know whether it's reasonable to wait 2.76.0. > > > > Our next release wave for providers is also slated for the beginning of > > August, > > so even if we make some workaround and force installing a 2020 (!) > > pre-release > > of betterproto release, we'd still prefer to wait for 2.76.0 as it > > would be a very > > temporary and pretty bad workaround. > > > > Thanks for making the fix, and for Beam generally. > > > > [1] https://github.com/apache/airflow/pull/61926 > > [2] https://github.com/apache/airflow/pull/66952 > > [3] https://github.com/apache/airflow/issues/66551 > > [4] https://github.com/apache/beam/pull/39213 > > [5] > > > https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com > > [6] > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/399278789/Release+Plan > > > > Jarek Potiuk > > Apache Airflow PMC > > >
