[apache-airflow] Update release cycles and dates

[adriens]

❔ About

Currently, airflow version are at a very high level :

... this makes it difficult to automate stack watching, for example when we are running a given 3.1 cycle or any 3.x or 2.x cycle... for maintenance purpose.

This PR is an attempt to enhance this, please let me know what you think about it.

💰 Benefits

• It makes it possible to monitor 3.x and 2.x cycles like we can on 1.x ones

[adriens]

Product Validator: Invalid releases '2.11' for apache-airflow.md,
expecting release (released on 2025-05-20) to be before 3.0 (released on 2025-04-23)

But it's indeed the reality :

🙏 How can I fix that ?

[adriens]

Brought me this idea about identifiers :

• [Request] An identifier for `HELM` chart #9005

[usta]

@adriens the releasecycle name is not important , it HAVE TO be in dateof release ordered ,
I mean it can be 1 , 2, 2.1 , 2.2 , 2.3 , 10 , 11 , 2.4 ( the only important date is THEIR release date ordering )

[usta]

To fix build I have fixed :
release orders
added date for 2.1 ( which was missing )
fixed a release date which was in future (you typed 2026 instead of 2016)

[adriens]

( the only important date is THEIR release date ordering )

Thanks a lot for all these tips @usta , I was not aware of the order importance 🙏

[usta]

@adriens i will be glad to help anytime brother :) Just check the dfifferences of source and you will understand what i mean

[adriens]

@adriens i will be glad to help anytime brother :) Just check the dfifferences of source and you will understand what i mean

Indeed, it makes totally sense that only date matters, not version names 🤔

[marcwrobel]

Release cycle are on the major version for 2 and 3 because the support is documented on major versions by Airflow, see https://github.com/apache/airflow#version-life-cycle.

So this change is not right IMO. Not to mention that:

• this is a breaking change, so it should be marked as such,
• it will make it hard/messy to document EOL dates once they are known because EOL date will have to change every time a minor version is released.

[adriens]

once they are known because EOL date will have to change every time a minor version is released.

yes, indeed, as both a ;

• Airflow user
• Enodlife client

I want to be able to know automatically I have to patch my minor version (eg. my helm chart) to get the latest one and be aware I should upgrde for example from 3.1 to 3.2... but with more rergression risks.

This is what motivates this PR in fact

[marcwrobel]

The main goal of endoflife.date is to provide information about release cycles, as well as their corresponding support and EOL policies in the most understandable way.

And, I don't understand what prevent you to do what you explained with the current data. Not to mention that minor version are not supposed to breaks things, at least most of the time.

Splitting the release cycles makes the page more complex, makes really hard to document EOL dates, and it makes more work for contributors (more updates are required).

[adriens]

And, I don't understand what prevent you to do what you explained with the current data. Not to mention that minor version are not supposed to breaks things, at least most of the time.

Yup, in fact it's due to the fact that the strategy depends on products, so, for a third party integration it's hard to know that. This is essentially what triggered this need

[marcwrobel]

Yup, in fact it's due to the fact that the strategy depends on products, so, for a third party integration it's hard to know that. This is essentially what triggered this need

The primary purpose of endoflife.date is to clearly present information about release cycles, support timelines, and end-of-life policies. Easier third-party integration is ok if it does not compromise this core objective. In this case it does, which is why I am not in favor of this change.

@endoflife-date/everyone any opinion regarding this PR ?

[usta]

My 2 cents is always same about rolling versioned products ( If they dont have different support life depends on previous versions ). So for me if a product ends support for previous versions directly we should fold all minor versions under major versions, i mean instead of listing all x.y versions are not helpful to endusers ( that job is for wikidata not for ours ).

In this example keeping all versions of 2.x and 3.x folded in 2 and 3 is much reasonable

[ again mentioning keeping old version release dates
( for products which never have different / overlaping support dates ) are not our mission ( afaik ) ,
thus our name is endoflife.date not whenitreleased.date ]

[adriens]

Ok, to add to te discussion, as Airflow implements semantic release, like traefik, for pepole using the api like I do, it's very convenient to be able to monitor/deploy a given version.

For traefik, I deploy the 3.5 image tag, so when the auto-update is done let's say from podman deploy, I know that i'm ok and will deploy all 3.5.x, conitnuously . I even can automte the check report on the very llatest version, le'ts say the 3.5.3 :

An once the 5.3 will be flagged as EOL, I know I will have to apply the major upgrade, wich may require to pay more attention to the maintenance process.

I have the same pattern for psql :

I deploy the 18 tag, I don't really have to pey attention to the minor release when I auto-upgrade this this service. I onlly have to pay attention to the major version, which could be the 13 or 14.. and then trigger or automate a waning issue whrn the 14 will fall EOL.

This is the core motivation for implrementin this kind od ov version scheme for airflow so API clients can implement this monitorig without any additional efforts.

The risk, in the current scheme is to not be able to propose effortless upgrades while missing important minor painless upgrades.

For example in the 3.X cycle, it's not the same risk to upgrade from a 3.1.2 to 3.1.3 than upgrading from a 3.1.3 to a 3.2.0.
Si I could which to stick for a moment on the latest of the 3.1.x and still being ok.

Hopefully this explains my need.

Without this, I 'm afradi I will have to implrement a workaround on the client side in this kind of situation. I guess it's due to the vesion scheme 🤔