Re: [VOTE] Remove experimental API

[Andrey Anshin]

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

Re: [VOTE] Remove experimental API

[Andrey Anshin]

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

Re: [VOTE] Remove experimental API

[Andrey Anshin]

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 
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  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  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
> 
> >> 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
> >>  
>  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 
> >>> wrote:
>  Would you still vote `-1`  of course was the question.
> > 

Re: [VOTE] Remove experimental API

[Xiaodong (XD) DENG]

-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  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  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 
>> 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
>> >>> 
 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 
>>> wrote:
 Would you still vote `-1`  of course was the question.
> On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk 
> 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

Re: [VOTE] Remove experimental API

[Mehta, Shubham]

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" 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 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 
> 
> 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  > 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  > 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 
> > > >
> > > 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
> > mailto:b...@astronomer.io.inva>lid
> > > >
> > > > wrote:
> > > >
> > > 

Re: [VOTE] Remove experimental API

[Andrey Anshin]

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

Re: [VOTE] Remove experimental API

[Elad Kalif]

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  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 
> 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
>  > >
> > > 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 
> > wrote:
> > > > >>> Would you still vote `-1`  of course was the question.
> > > >  On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk 
> > > > 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
> > > > >>> 
> > > > > 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
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Remove experimental API

[Hussein Awala]

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 
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  >
> 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  >
> > 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 
> wrote:
> > > >>> Would you still vote `-1`  of course was the question.
> > >  On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk 
> > > 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  >
> > > >>> 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
> > > >>> 
> > > > 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
> > >
> > >
> >
>

Re: [VOTE] Remove experimental API

[Vikram Koka]

-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 
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 
> 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 
> > 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  >
> > >> 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  wrote:
> > >>> Would you still vote `-1`  of course was the question.
> >  On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk 
> > 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 
> > >>> 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
> > >>> 
> > > 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
> >
> >
>

Re: [VOTE] Remove experimental API

[Daniel Imberman]

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 
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 
> 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 
> >> 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  wrote:
> >>> Would you still vote `-1`  of course was the question.
>  On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk 
> 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 
> >>> 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
> >>> 
> > 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
>
>

Re: [VOTE] Remove experimental API

[Bas Harenslak]

-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  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 
>> 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  wrote:
>>> Would you still vote `-1`  of course was the question.
 On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk  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 
>>> 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
>>> 
> 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

Re: [VOTE] Remove experimental API

[Andrey Anshin]

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 
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  wrote:
>
>> Would you still vote `-1`  of course was the question.
>>
>> On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk  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 
>> 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
>> 
>> >> wrote:
>> >> >I forgot to add the "why" - I view this as a breaking change still.
>> >>
>> >
>>
>

Re: [VOTE] Remove experimental API

[Andrey Anshin]

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

> Would you still vote `-1`  of course was the question.
>
> On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk  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 
> 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  >
> >> wrote:
> >> >I forgot to add the "why" - I view this as a breaking change still.
> >>
> >
>

Re: [VOTE] Remove experimental API

[Jarek Potiuk]

Would you still vote `-1`  of course was the question.

On Sat, Mar 16, 2024 at 8:37 PM Jarek Potiuk  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  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 
>> wrote:
>> >I forgot to add the "why" - I view this as a breaking change still.
>>
>

Re: [VOTE] Remove experimental API

[Jarek Potiuk]

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  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 
> wrote:
> >I forgot to add the "why" - I view this as a breaking change still.
>

Re: [VOTE] Remove experimental API

[Ash Berlin-Taylor]

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  
wrote:
>I forgot to add the "why" - I view this as a breaking change still.

Re: [VOTE] Remove experimental API

[Jed Cunningham]

I forgot to add the "why" - I view this as a breaking change still.

Re: [VOTE] Remove experimental API

[Jed Cunningham]

-1. Even though it's been deprecated for a really long time now, I don't
think we should remove it in a minor 2 release. I think we should wait
until the next major.

Re: [VOTE] Remove experimental API

[Jarek Potiuk]

+1 (binding)

On Sat, Mar 16, 2024 at 1:14 PM Andrey Anshin 
wrote:

> Greetings everyone!
>
> I would like to start a vote proces about removal of Experimental API
> support into the next minor Airflow version, presumably 2.9, but it could
> be postponed to 2.10.
>
> By default experimental REST API turned off, and we recommend to use stable
> REST API:
>
> https://airflow.apache.org/docs/apache-airflow/stable/deprecated-rest-api-ref.html
>
> Discussion about deprecate and remove support of Experimental API started
> in 1.10
> - Dev List:
> https://lists.apache.org/thread/jdz9l7bsnsw5c3t27dxfrx5pd4wvjlxt
> - Github Issues: https://github.com/apache/airflow/issues/10552
>
> And recently:
> - https://lists.apache.org/thread/khl7gvzpcv3kn99zc441wb9m2dyz4gp9
>
> The vote will last until 13:00 GMT/UTC on March 22, 2024, and until at
> least 3 binding votes have been cast.
>
> Please vote accordingly:
>
> [ ] + 1 approve
> [ ] + 0 no opinion
> [ ] - 1 disapprove with the reason
>
> Only votes from PMC members and committers are binding, but other members
> of the community are encouraged to check the AIP and vote with
> "(non-binding)".
>

[VOTE] Remove experimental API

[Andrey Anshin]

Greetings everyone!

I would like to start a vote proces about removal of Experimental API
support into the next minor Airflow version, presumably 2.9, but it could
be postponed to 2.10.

By default experimental REST API turned off, and we recommend to use stable
REST API:
https://airflow.apache.org/docs/apache-airflow/stable/deprecated-rest-api-ref.html

Discussion about deprecate and remove support of Experimental API started
in 1.10
- Dev List: https://lists.apache.org/thread/jdz9l7bsnsw5c3t27dxfrx5pd4wvjlxt
- Github Issues: https://github.com/apache/airflow/issues/10552

And recently:
- https://lists.apache.org/thread/khl7gvzpcv3kn99zc441wb9m2dyz4gp9

The vote will last until 13:00 GMT/UTC on March 22, 2024, and until at
least 3 binding votes have been cast.

Please vote accordingly:

[ ] + 1 approve
[ ] + 0 no opinion
[ ] - 1 disapprove with the reason

Only votes from PMC members and committers are binding, but other members
of the community are encouraged to check the AIP and vote with
"(non-binding)".