> 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> 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 > > > > > > > > > > > > > > > > > > > >
