Agreed with the discussion topics above, I too think 6 month of maintenance + 6 of security maintenance is a fair statement to make.
We should also clarify and make it absolutely explicit about what "maintenance" means in this context to avoid any surprises in the future. Thanks & Regards, Amogh Desai On Wed, Apr 23, 2025 at 8:03 PM Jarek Potiuk <ja...@potiuk.com> wrote: > I think 6+6 is good. > > But - maybe a bit controversial - and maybe we do not need it. But I think > we should be very clear about setting some expectations for our users about > what "maintenance" and "security maintenance" is, not only to tell numbers. > At the very minimum we should add a comment to refer to point 7 of the > ASF-2.0 licence (below): > > I think the discussion is a bit wrongly named - this should be > "maintenance" not "support" - just to not mistake it with "support/SLA" > kinds of expectations. When you pay 0 for the software, you cannot have any > expectations for support (and our licence is pretty clear about it as > well). But people have different expectations of what "support" or > "maintenance" is.: > > So I think we should - even between ourselves - agree what the 6+6 means. > > Even with security vulnerabilities or fixes, there is nothing (so far at > least) that forces us and no promise we make to our users to release a > patch for any such issue - including serious ones (at least so far there > was not). We could say "upgrade to Airflow 3 to address it". Even today, > we have not fixed nor even responded to all the issues reported to us in > Airflow 2 (there are many) and there is no chance we will fix (or even > respond to) all of them to be honest. Including any future ones. > > We could as well promise that we "accept issue reports" for 6 months and > security reports for the following 6 months and possibly we do "something" > with it. So far even within Airflow 2 we have not promised anything more > than that. > So - at least so far what's the reality - this 6+6 is really "we accept > reports" rather than "ignore them straight away and ask the users to > upgrade". That would be my definition of the 6+6 at least - looking at the > reality we operate in and at the way we did it so far - including what > happened in Airflow 2. > > It does not mean we will fix all reported issues for Airflow 2 within the 6 > months (or that we will fix all security issues reported to Airflow 2 > during the 12 months). That would be way more than what we even do today. > > Note that things might change in the future - with CRA / security - but > those will be obligations of those who put the software on the market, to > make sure critical security fixes are addressed for 5 years, but this yet > to be defined what it means for the foundation/ stewards and what it means > from those who commercially publish Airflow. And it might also mean that > commercial users might patch and fix on their own as well after we stop > doing it in the community. > > Happy to help drafting it, but it might be the right time to clarify what > "maintenance" is - especially if we want to add "security maintenance". at > the very minimum we should refer to this clause of the licence: > > 7. Disclaimer of Warranty. Unless required by applicable law or > agreed to in writing, Licensor provides the Work (and each > Contributor provides its Contributions) on an "AS IS" BASIS, > WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > implied, including, without limitation, any warranties or conditions > of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A > PARTICULAR PURPOSE. You are solely responsible for determining the > appropriateness of using or redistributing the Work and assume any > risks associated with Your exercise of permissions under this License. > > J., > > > On Tue, Apr 22, 2025 at 10:28 PM <consta...@astronomer.io.invalid> wrote: > > > 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 > > > > >
