There is no specific rush, in case it is considered as experimental feature, this vote shows that it is not, it might be removed in any minor release. Benefit: remove legacy/unsupported/unmaintained code from codebase, rather than move it into the separate component (if someone wanted they might propose this solution)
On Tue, 19 Mar 2024 at 22:46, Xiaodong (XD) DENG <xd.d...@apple.com.invalid> wrote: > -1 for removing it now. > > The reasons have already been elaborated by folks here sufficiently (My > team is an example of using experimental API heavily so far. The ideal > situation is of course to already catch up with the latest features, like > to use REST API. But the reality is reality). > > Let’s honor the sentimental versioning. It should not be something to be > done in 2.x. > And what’s the benefit of rushing to remove it in 2.9 or 2.10? > > > Regards, > XD > > > On Mar 17, 2024, at 01:42, Elad Kalif <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 > > 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> 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.invalid> > >> 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 > >>>> > >>> 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.invalid > >>>> > >>>> 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> > >>>>> 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 > >>>>> > >>>>>>> wrote: > >>>>>>> I just wonder if `Experimental` is covered by > >>>>>>> > >>>>> > >>>> > >>> > >> > 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> > >>> 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> > >>>>> 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 > >>>> > >>>>>>>> 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.INVALID> > >>>>>>>>>> wrote: > >>>>>>>>>>> I forgot to add the "why" - I view this as a breaking change > >>>> still. > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> 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 > >
