When I prepared the voting results I figured out that I do not vote by myself.
So here my +1 binding On Wed, 20 Mar 2024 at 22:40, Andrey Anshin <andrey.ans...@taragol.is> wrote: > 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 >> >>
