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 > >
