potiuk commented on issue #35644: URL: https://github.com/apache/airflow/issues/35644#issuecomment-1820995470
> I've found some grey area of Public interface, There are probably plenty. It's open for contribution to clarify them as usual :). SemVer is very clear about this, https://semver.org/ SemVer is a "communication" tool. It is about communication of our intentions about what our public API does, not about making sure all implementation details follow strict "I do not change this/ I change that" policy. > Statement 1. AirflowTaskTimeout it is internal part of core and should only use in the core because it might change behaviour of different part of Airflow I'd modify it a bit. The existence of AirflowTaskTimeout (with intent of being an exception to be thrown when timeout occures is Public. The implementation and fact that it derives from BaseException or Exception is internal implementation details. If we change it, we should tell it but it does not change the intention. Public APIs are usually about intentions not about details. Someone **COULD** rely on the implementation detail of it being based on Exception but this was not the **intention** we had. Hyrum's law is very clear about it (and I fully agree with it). Any change has potential of breaking someone's workflow. But Public APIS are intentions, not promises - and the change here which i see is that we clarify the intention we had with that exception. > Statement 2. Rule 1 should also apply to Community Providers Yes. Applies well - intention of signifying timeout is Public, all the other details being internal implementation details. > Statement 3. If they are used according to the intention (finding out when the task had been timed-out and reacting to it somwhow) - all is cool. There is no conflict. The conflict is only if someone used it assuming that it will always be derived from BaseException (we never intended that). If you used it :-1: ```python try: do something except Timeout: /// react somehow ``` All is fine and well. We will have cases that we break someone's workflow. TOUGH. We will have to bite the bullet. If we have not clarified our intentions well enough before - it might be even seen as our fault. Also tough. But with clarifying intentions we are moving closer and closer to the place that most of our Publiic APIs is listed and intentions explained. This should be our goal. -- 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]
