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
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
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
-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
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.
> 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
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
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
-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
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
-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
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
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
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
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
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.
I forgot to add the "why" - I view this as a breaking change still.
-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.
+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
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:
20 matches
Mail list logo
