Doing some back of envelope math:

6/12 (or 6+6) gets you to April 2026 (October 2025 for bug fixes). If we follow 
the pre-3.0 release cadence, we will release 3.1 beginning of August and 3.2 in 
December. Assuming the policy goes through, by the time we stop patching 2.10 
with bug fixes, 2.10 will be roughly 14 months old and should be relatively 
stable, and 3.1 will be roughly 2 months old. By the time we stop patching 
security fixes for 2.10 in April 2026, we should have already released 3.2 and 
it should be 3-4 months old, and will likely be releasing 3.3 at a similar 
time. 

I think the policy is reasonable as is gets my vote. If we feel the need to 
extend parts of it as we get closer to these key dates, we will always have the 
option. 



> On Apr 22, 2025, at 3:56 PM, Jens Scheffler <j_scheff...@gmx.de.invalid> 
> wrote:
> 
> Hi, sorry was focussing on too many other "balls in the air"...
> 
> As discussed during dev call as well (replicate as text here) we are most 
> probably also only able to migrate over once 3.1 is available. For us it is 
> rather the missing UI support for plugins that also leaves a gap to todays 
> solution for edge worker maintenance. (see 
> https://github.com/apache/airflow/issues/49536)
> 
> But I'd also understand that it does not make sense to nail down the support 
> policy based on a future 3.1 release. I assume if people start migrating then 
> 3-6 months from 3.1 is realistic (assuming all critical features are 
> contained) which is very similar as if we say 6 months fixes and 6 additional 
> months for security only (to "keep the lights on" for all still not migrated 
> to be at least compliant).
> 
> Therefore I'd agree to the proposal from Kaxil to define 6+6 from TODAY.
> 
> Jens
> 
>> On 22.04.25 12:33, Pankaj Koti wrote:
>> I think having a baseline maintenance policy could still be beneficial
>> overall.
>> Would it be possible to set an initial maintenance support period of “x”
>> months,
>> with the flexibility for the PMC to extend it if blocking migration issues
>> are
>> reported -- taking into account the time needed to resolve them? Providing a
>> 6-month (or similar) period could help motivate adoption of Airflow 3 while
>> also
>> giving us a chance to gather early feedback and respond accordingly.
>> 
>>> On Tue, Apr 22, 2025 at 3:47 PM Elad Kalif <elad...@apache.org> wrote:
>>> 
>>> We need to remember that some organizations may not be able to migrate to
>>> Airflow 3 right away (for example: SLA -> Deadline alerts migration).
>>> Thus I think it should be 6 months after 3.1 or at least 3-6 extra months
>>> after 3.1 of bug fixes for issues that are reported as blocking migrations
>>> to 3 and PMC members / release managers agree with that. That gives the
>>> flexibility of still being able to deliver fixes yet with some control over
>>> what is included.
>>> 
>>>> On Tue, Apr 22, 2025 at 12:56 PM Kaxil Naik <kaxiln...@gmail.com> wrote:
>>> 
>>>> Any thoughts on this? I would like to ideally include it in the docs
>>> before
>>>> Airflow 3.0.0 goes out. But if I don't hear much, I would patch the docs
>>>> after.
>>>> 
>>>> On Fri, 18 Apr 2025 at 00:23, Kaxil Naik <kaxiln...@gmail.com> wrote:
>>>> 
>>>>> Hey team,
>>>>> 
>>>>> With the release of Apache Airflow 3.0.0 around the corner, I’d like to
>>>>> open a discussion about the future of support for Airflow 2.x.
>>>>> 
>>>>> We touched on this during today’s dev call, and there was broad
>>> consensus
>>>>> around the following initial plan:
>>>>> - 6 months of maintenance support for "bug fixes"
>>>>> - 12 months of maintenance support for "security fixes"
>>>>> 
>>>>> Both timelines would begin from the official Airflow 3.0.0 release
>>> date.
>>>>> For context: When Airflow 2.0 was released, we supported Airflow 1.10.x
>>>>> for 6 months post-GA, as documented here [1] and in our README [2]. The
>>>>> general sentiment on the call was to start with these timelines and
>>>> adjust
>>>>> later if needed based on user feedback or ecosystem needs.
>>>>> 
>>>>> This will be documented in the Readme [2] and in the upgrade guide [3],
>>>> so
>>>>> users are clear on the support timeline and aren’t left concerned that
>>>>> Airflow 2 support ends abruptly -- once folks have had a chance to
>>>> discuss
>>>>> it here.
>>>>> 
>>>>> Regards,
>>>>> Kaxil
>>>>> 
>>>>> [1]:
>>>>> 
>>> https://airflow.apache.org/docs/apache-airflow/stable/howto/upgrading-from-1-10/index.html#support-for-airflow-1-10-x-releases
>>>>> [2]:
>>>>> 
>>> https://github.com/apache/airflow?tab=readme-ov-file#version-life-cycle
>>>>> [3]:
>>>>> 
>>> https://github.com/apache/airflow/blob/main/airflow-core/docs/installation/upgrading_to_airflow3.rst
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> For additional commands, e-mail: dev-h...@airflow.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org

Reply via email to