potiuk commented on PR #27866:
URL: https://github.com/apache/airflow/pull/27866#issuecomment-1329736900
> What is not 100% clear from the documentation in our case is that Cloudera
provider would be introduced with a min dependency of 2.3.0.
Yes. As a rule comunity does not maintain pre-2.3.0 providers as of October
11th 2022 (12 months after 2.2.0 was released). Any new providers accepted will
have to follow that rule, otherwise it would require extra maintenance burden
for the community.
You can still release your providers in the version which is compatible with
2.3.0. Differnt package and maintained by Cloudera.
> In the case we want to maintain compatibility for older versions, we
would have to open a PR with this provider against an older version of Airflow,
and it would automatically be released (however only technically, only
supported by the maintainer and not the community) with the next wave of
provider release along with the latest version of the provider, which is
supported by the community? Is this statement correct?
No it's not. We never release any new provider which is compatible with
pre-2.3.0 (currently - in April it will be 2.4.0) Airlfow version. We can
at-most release patchlevel (bugfix) version with only changes that are
cherry-picked from main - no new features, no new providers either.
This patchlevel release is never automatic and we actually have never
expected to release providers for older versions - we have no process for that
- the process that we have is prepared for releasing a bugfix-only (patchlevel
no new featurs) to already released old provider version (and there the burden
is on someone who wants to do it and only cherry-pick existing changes and
update release documentation - then we might attempt to release it, but this
should always be exceptional case involving communication on the devlist and
announcing the readiness of it. Basically whoever takes lead there up to the
last moment of preparing the package, is responsible for building and testing
it.
But this is not even your case now. We have no automation (nor time to help
in updating our automation) to just release old versions of new provider
retroactively. If we accept it, we will release 2.3.0+ only and if you want to
release a compatible package with pre-2.3.0 support (but with different name -
you should never release anything which have apache-airflow-providers-* in PyPI
without going through Apache Airflow release process). And then you are fully
on your own with compatiblity/bugfixes etc. Of course that's my point of view,
and you can convince the community to do it otherwise, but I am not even sure
what to do if this approach will be taken.
Also - regardless of the above rules that we have in the community - I
think you should call for a vote on a devlist for the community, whether we
want to accept the provider. We are not automatically accepting any provider,
it has to be justified and there various people and various opinions whether we
should accept maintenance of more providers or not. Accepting a provider is
not only "benefit" but also "burden" that community will have to accept.
I believe it is quite substantial piece of code that you want to hand-over
to Apache Software Foundation, with some extra dependencies and we need to make
sure we really want to take over the maintenance of it.
Since you have now PR and we know the full extent of it, I suggest you start
voting thread on our devlist
https://www.apache.org/foundation/voting.html#votes-on-code-modification with
some justifications and let's see what the voting decide. Havig the PR,
looking at the code/quality and the burden it will be easier to make the
decision I think - but I believe it is important-enough case to call for a
formal vote rather than rely on simple PR approval.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
