Thanks for voting and your opinions. Here are the results Please note that the only votes counted about removal from Airflow 2.x codebase, if we would like to move it into the separate provider, we should discuss it first.
-1: 6 votes: Jed Cunningham, Ash Berlin-Taylor, Bas Harenslak, Daniel Imberman, Vikram Koka, Xiaodong Den +1: 3 votes: Andrey Anshin, Jarek Potiuk, Hussein Awala +0: 1 vote: Elad Kalif On Fri, 22 Mar 2024 at 15:43, Andrey Anshin <andrey.ans...@taragol.is> wrote: > 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 >>> >>>
