potiuk commented on issue #20398:
URL: https://github.com/apache/airflow/issues/20398#issuecomment-997803634
> Sorry @potiuk I should have asked a better question. I want to do a
breaking change (albeit a very tiny and not super significant one) by having
the hook no longer store query ids on the instance.
> But I know that we don't want to do major releases all the time. Maybe
this isn't "significant enough" to even do? Does it have to wait until there
are other bigger changes?
I think it's best to discuss it in PR. I am not able to give authoritaive
answer as I am not "single point of decision" - but having PR and few eyes
looking at that and reaching consensus is always best approach.
I personally think that the first question in such cases should be - Can we
do it in a non-braking fashion (with optional parameter and deprecation
warning) that will have low to medium maintenance and code overhead?
If the answer is yes - this is the preffered way. If in doubt we should
always err on the side of backward compatibility. Our users are part of the
community and "stability" for them and "least surprise" principle is much more
important that slight improvement of maintainer's convenience.
I think If we have aa good reason that the changes cannot be done in
backwards-compatible way, or they would involve significant maintenance
overhead or the decisions or coming from external factors (for example as we
had with google upgrading all it's libraries in backwards-incompatible way),
then and only then we shoudl go for updating major version of the provider and
backwards incompatibility.
Now - in this case, I am not 100% sure how the change will look like, and
there is no reason why we should make the decisions before we see the code.
When we see the PR and comment, there is always a chance to revert the decision
- and either make it backwards-compatible if we see that the maintenance
overhead is acceptable, or decide to break compatibility if we see that we will
complicate the code too much or we think that users could benefit from breaking
the compatibility.
It's your decision as PR creator to choose the proposed approach, and
further disusssion and consensus among the rviewers to agree if it's a good
decision.
--
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]
