Amazon MWAA should not act as a blocker to the removal of the experimental API. We have already surpassed the end of support date for v1.10 on MWAA, which was February 21st, 2024. While customers may continue to use their existing v1.10 environments, we do not intend to introduce new features.
However, I agree with the sentiment that Airflow should not remove this feature, as it would disrupt automations relied upon by our users. Additionally, as far as I know "experimental" designation in the release process was implemented after v2.1 (https://github.com/apache/airflow/pull/18139). So, users who began utilizing this feature were likely unaware of the policy at the time. As a potential solution, I wonder if we can add a clear deprecation notice indicating that this feature will be phased out following the x.ab (for instance, 2.11) release. This warning would provide users approximately six months to transition away from the experimental API. This can expedite the process, rather than waiting for the v3.0 release, which might not occur for several years. Shubham On 2024-03-17, 2:19 AM, "Andrey Anshin" <andrey.ans...@taragol.is <mailto:andrey.ans...@taragol.is>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. > I think we better wait at least till major cloud vendors of Airflow stop > supporting older versions of Airflow I guess there is not a big problem > from my check both AWS AWS MWAA never support REST API on Airflow 1.10, and I'm not sure that it support it even support stable REST API in 2.x releases > and Google still support 1.10 On March 25, 2024, Cloud Composer 1 will enter its post-maintenance mode On Sun, 17 Mar 2024 at 12:43, Elad Kalif <elad...@apache.org <mailto:elad...@apache.org>> wrote: > I am -0 for removal at this time. > I think we better wait at least till major cloud vendors of Airflow stop > supporting older versions of Airflow from my check both AWS and Google > still support 1.10 > I see that Google supports it until September 13, 2024 > > https://cloud.google.com/composer/docs/concepts/versioning/composer-versions > <https://cloud.google.com/composer/docs/concepts/versioning/composer-versions> > while not mandatory it may be easier for users to migrate from 1.10 to 2.x > if they have one less thing to worry about and they could handle the > experimental -> stable API later on once they are on Airflow 2.x > > As for the provider suggestion I am -1 > There are no problems or maintenance overhead (that I know of) with keeping > the experimental API within core. > What is the value of having it as a provider package? It will get no more > fixes or features so how does extracting to the provider package helps? > While this is a voting thread the discussion thread was not about this > suggestion. We may need to restart discussion before we vote on this > alternative. > > > On Sun, Mar 17, 2024 at 4:50 AM Hussein Awala <huss...@awala.fr > <mailto:huss...@awala.fr>> wrote: > > > For me, this is one of the experimental features that we can remove at > any > > time according to our release process. For the users who are using it, I > > don't think they are using a recent version of Airflow because this API > has > > been deprecated since 2.0.0 and we haven't added any features or fixes to > > it in over three years. > > > > +1 to remove it. > > > > But since we already have some -1 binding votes, I like to move it to a > > separate provider as an alternative solution. > > > > On Sun, Mar 17, 2024 at 3:34 AM Vikram Koka <vik...@astronomer.io.inva > > <mailto:vik...@astronomer.io.inva>lid > > > > wrote: > > > > > -1 > > > > > > As much as I would like to see this removed, I feel the same way as Jed > > > above. > > > > > > In response to the question raised regarding "Experimental features", > the > > > reason why this one seems different is because though this was marked > as > > > "experimental", it was the only way to interact with Airflow before the > > > full fledged REST API and therefore a lot of users had baked this > > > experimental API into their automation processes. > > > > > > > > > On Sat, Mar 16, 2024 at 5:37 PM Daniel Imberman < > > daniel.imber...@gmail.com <mailto:daniel.imber...@gmail.com> > > > > > > > wrote: > > > > > > > As everyone above mentioned. I’m all for removing it but we should do > > so > > > as > > > > part of a major breaking release. Perhaps if we haven’t already we > > should > > > > at least add deprecation warnings? > > > > > > > > -1 but very down to add deprecation warnings > > > > > > > > On Sat, Mar 16, 2024 at 4:19 PM Bas Harenslak > > <b...@astronomer.io.inva <mailto:b...@astronomer.io.inva>lid > > > > > > > > wrote: > > > > > > > > > -1 for me too. > > > > > > > > > > Regardless of how we treat the “experimental” status, I often still > > see > > > > > people using the experimental API for triggering DAGs. IMO it would > > be > > > > too > > > > > much of a breaking change to remove it in a minor version, so I > > suggest > > > > > removing it in Airflow 3. > > > > > > > > > > Bas > > > > > > > > > > > Op 16 mrt 2024 om 14:24 heeft Andrey Anshin < > > > andrey.ans...@taragol.is <mailto:andrey.ans...@taragol.is>> > > > > > het volgende geschreven: > > > > > > > > > > > > Asked because if it never was an experimental feature, then it > > can't > > > > be > > > > > > just removed until Airflow 3 which might never happen. > > > > > > In this case the vote should be canceled, and we need to continue > > to > > > > > > discuss moving it to a separate provider and suspend/remove the > > newly > > > > > > created provider. > > > > > > > > > > > > > > > > > > > > > > > >> On Sun, 17 Mar 2024 at 00:02, Andrey Anshin < > > > andrey.ans...@taragol.is <mailto:andrey.ans...@taragol.is> > > > > > > > > > > >> wrote: > > > > > >> I just wonder if `Experimental` is covered by > > > > > >> > > > > > > > > > > > > > > > https://airflow.apache.org/docs/apache-airflow/stable/release-process.html#experimental-features > > <https://airflow.apache.org/docs/apache-airflow/stable/release-process.html#experimental-features> > > > > > >> ? > > > > > >> Or is it just another meaning of Experimental ? > > > > > >>> On Sat, 16 Mar 2024 at 23:39, Jarek Potiuk <ja...@potiuk.com > > > > > >>> <mailto:ja...@potiuk.com>> > > > wrote: > > > > > >>> Would you still vote `-1` of course was the question. > > > > > >>>> On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk < > ja...@potiuk.com <mailto:ja...@potiuk.com>> > > > > > wrote: > > > > > >>>> Question: Jed, Ash: Would you still vote If we move it to > > provider > > > > > (with > > > > > >>>> status "removed from maintenance except security fixes" - same > > as > > > we > > > > > did > > > > > >>>> with daskexecutor? > > > > > >>>> J. > > > > > >>>> On Sat, Mar 16, 2024 at 8:25 PM Ash Berlin-Taylor < > > a...@apache.org <mailto:a...@apache.org> > > > > > > > > > >>> wrote: > > > > > >>>>> As much as I would love to remove it I'm with Jed: if it > worked > > > on > > > > > 2.0 > > > > > >>> it > > > > > >>>>> should work on all 2.x > > > > > >>>>> My vote is -1 > > > > > >>>>> On 16 March 2024 19:08:13 GMT, Jed Cunningham > > > > > >>> <j...@astronomer.io.inva <mailto:j...@astronomer.io.inva>LID> > > > > > >>>>> wrote: > > > > > >>>>>> I forgot to add the "why" - I view this as a breaking change > > > > still. > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > > > > > <mailto:dev-unsubscr...@airflow.apache.org> > > > > > For additional commands, e-mail: dev-h...@airflow.apache.org > > > > > <mailto:dev-h...@airflow.apache.org> > > > > > > > > > > > > > > > > > > > >
