potiuk commented on code in PR #28900:
URL: https://github.com/apache/airflow/pull/28900#discussion_r1429319698
##########
airflow/models/dag.py:
##########
@@ -1383,8 +1384,43 @@ def normalized_schedule_interval(self) ->
ScheduleInterval:
_schedule_interval = self.schedule_interval
return _schedule_interval
+ @staticmethod
+ @internal_api_call
@provide_session
- def handle_callback(self, dagrun, success=True, reason=None,
session=NEW_SESSION):
+ def fetch_callback(
Review Comment:
Agree it's not "disappearing" now so not an issue.
But I also would like to have a bit of philosophical rant here.
I thnk we are approaching backwards compatibility here as "0 / 1". And I
keep on repeating it's totally wrong. Hyrum's right is totallly right here:
https://www.hyrumslaw.com/ - in sufficiantly complex system ANY change is
braaking. You would have to stop changing things to stop things from breaking.
There is no way around it. And we cannot describe super precise rules about it
upfront. We cannot really say:
* any time we change this and that, we are technically breaking things
That would make us slow and very shortly we would lose any flexibliity. I
think we will never achieve 100% correctness and sets of rules that will
clearly say for each change "breaking/not breaking" in automated way. We can
approach it and get closer to it by adding more and more rules and description
- but we will at most asymptotically get closer to the certainty - never
achieving it and at some point in time, adding more and more rules will make it
more not less confusing and contradicting. So we should strive for 'good
enough" and "pretty correct" set of rules - but also accept the fact that there
will be exceptions and room for interpretation and even for arbitrary decisions
that others (including some of our users) might not agree with.
As I see it (and What I think SemVer also explains) Backwards Compatiility
ad Semver is NOT about following certain rules "adding a parameter is breaking,
renamig any method no marked as private is breaking". IMHO tis is about three
things:
1) what is the INTENTION we had when we created the code - were we INTENDING
to make it breaking? Was described and explained that users were supposed to
rely on it ? Or was their reliance on certain methods and fields accidental
and the fact that method was there was just "assumed" they can rely on it?
2) how likely it is tha many of our users made such assumptions if it was
not clearly documented, and explained - or even if they could take the
impression it was, how likely it is we are breaking something sersious.
3) How difficult it is to recover for our users. If the system is failing
immediately and what the user needs to do is flipping the flag to bring back
the old behaviour - is it breaking or not? If the system is not failing but the
change in behaviour is not persistent nor dangerous and the user might bring it
back with a flip of a flag - is it breaking or not?
And yes - it means we will sometimes have to make arbitrary decisions based
on gut feelings not data nor precise rules followed. And yes - it means that
sometimes there will be individual angry users who will tells us "but you
promised backwards compatibiliity - bring it back NOW", and there will be cases
where we disageree between ourselves - maintainers - what is backwards
compatible and what is. not and we will have to vote on it eventually. And yes
- sometimes it will mean we will take a wrong decisiion and break too many
workflows of too many users and we will have to quickly release a bugfix that
will revert it.
All this. And more. And we will remains humans making sometimes flawed and
imperfect decisions based on our insticts and intentions and gut feelings not
data and strict rules - rather than robots following precise rules and
prescribed algorithms. I thin this is why we - as maintainers are still needed
in the project - to make such decisions.
Sorry If I've gotten a bit too philosophical, but I do think we are quite
too often trying to make things crystal clear and be free of making the
decisions so that we don't have to well, make decisions. It's needed in many
cases - that's why I am also adding a lot of rules on how we approach things -
for example provider's maintenance lifecycale. But I treat it more as
communication tool and write down our intentions and where possible leave
enough room for interpretation and decision making. Where we can - yes we
should make clear rule. But when we can't we should state our intentions,
communicate general principles, and simply try - as best as we can - to fulfill
those stated intentions.
--
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: commits-unsubscr...@airflow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
