BTW. "Workers from 2.2" used with "Airflow 2.4" is not even a thing. This is something that you should never, ever, try to do. This is even more common sense, and there are of course limits of what you can describe in the docs (whatever you come up with, someone might have a super crazy idea that you have not thought about and - for example - run Airflow 1.10 worker With Airflow 2 (why not? We have not written it should not happen).
But one of the good things about having an explicit policy that in case of doubt we (community) can decide rather than let the code decide what is breaking or not (regardless if it has been previously documented or not), makes it much more flexible and less vulnerable for trolls who would like to use that argument of "breaking/not breaking" as "reductio ad-absurdum". What is important here is our (community) intention and reasoning (and finally consensus or voting) rather than letting "code" or "documentation" (which might be wrong) decide on it. "Community over code" in full swing here. J. On Tue, Nov 22, 2022 at 11:28 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > Changing the DB schema has never been "breaking". This is implicit, > not really "explicitly" documented as breaking classification. And > this is also the case which I refer to as the "common sense" - and > also another example where "common sense" is not enough. > > Since we introduced a stable REST API, the API should be used by any > "external usage" not DB. This has been explained in release notes of > Airflow 2.0 and probably in quite a number of issues and discussion > and since Airflow 2.0 the "common sense" statement is "we can change > the schema at any time and you should not rely on it, use REST API > instead". > > But yes, I imagine some people might not be aware of it. It's > certainly not written in our docs: > > https://airflow.apache.org/docs/apache-airflow/stable/release-process.html > > BTW. The docs there are pretty vague "Although Airflow follows SemVer > this is not a promise of 100% compatibility between minor or patch > releases, simply because this is not possible: what is a bug to one > person might be a feature another person is depending on." - this is > Hyrum's Law explained in different words. But IMHO we do not have any > explanation on what "breaking vs. not breaking" is and how we decide > on it. > > So I think part of the more detailed "policy" that we might consider > is to specify explicitly that "DB changes are not breaking". We could > specify it verbatim in any new section in our documentation "What we > consider (or not) as a breaking change?". > > J. > > On Tue, Nov 22, 2022 at 10:56 AM Alexander Shorin <kxe...@gmail.com> wrote: > > > > The rule of breaking changes also applies to database schema as well, > > right? Because currently, almost every minor release is breaking since you > > cannot run workers from 2.2.x with a database from 2.4.x. > > > > -- > > ,,,^..^,,, > > > > > > On Tue, Nov 22, 2022 at 12:32 PM Jarek Potiuk <ja...@potiuk.com> wrote: > >> > >> Hello everyone, > >> > >> We had a few discussions in PRs recently about removing some > >> functionality from the Airflow Core and the question of backwards > >> compatibility came up. Example two discussions: > >> > >> * https://github.com/apache/airflow/pull/27826 > >> * https://github.com/apache/airflow/pull/27067 > >> > >> I think we should collectively decide if we are ok to remove some > >> features from Airflow Core which are likely not heavily used and which > >> we assess as not risky, and we are willing to take the risk. > >> > >> # Current status with SemVer: > >> > >> We have SemVer which means that we cannot release Airflow 2.* with any > >> breaking change. Breaking changes should go to 3. Regarding what > >> "breaking change is", my definition is: > >> > >> * any removal of any functionality (except experimental) is > >> automatically breaking > >> > >> * any change of public "Interface" is breaking (though we have no > >> formal definition of what "public interface" is - there were a few > >> things that were implicitly seen as "public interface" (Variables, > >> Connections for example) - but it is a bit blurry what "public > >> interface" means > >> > >> However this is just what **I** think was the approach we used so far > >> at least. Others might have different ideas and understanding of what > >> "breaking" is, and I think this is the main problem we have: we do not > >> have a common understanding nor definition of what "breaking" is. We > >> simply do not have it. One might say it is a "common sense", and I was > >> also thinking like that - that was obvious, but after being involved > >> in a number of discussions I started to change my thinking about it. > >> > >> # My current view > >> > >> My point (and something that I actually learned about recently) is > >> that there is no "objective" definition of "breaking". Quite recently > >> Hyrum's law https://www.hyrumslaw.com/ started to circulate the IT > >> world, I've heard of it several times and the more I think about it, > >> the more I think the more I agree with it. The law summary is: > >> > >> "With a sufficient number of users of an API, it does not matter what > >> you promise in the contract: all observable behaviors of your system > >> will be depended on by somebody." > >> > >> This basically means that no matter how hard you try - any release you > >> make will be somewhat breaking. > >> > >> My current interpretation/understanding is that really "breaking" is > >> not 0/1 - it is continuum and the definition of "breaking" is for me > >> "how likely it is that the change will break many people's workflows > >> in the way it will be difficult for them to recover". Yes, there are > >> some "obvious" cases and there I think we know what is breaking, but I > >> am talking about some cases that are less obvious (like the two cases > >> above). > >> > >> I believe we introduced SemVer in Airflow for one reason - to make our > >> users more confident that they can migrate easily without introducing > >> breaking changes. And I think this is still a good idea and good > >> cause. And we should continue doing that. However what we can change > >> is what we see as our "breaking" definition and that we start taking > >> risks. Risks that we will break someone's workflow when we introduce a > >> change. I think we could take the risk in some cases (the two cases > >> above) where we agree that the risk is low and that we provide an easy > >> way to recover for those few users who will hit it. > >> > >> # My Proposal > >> > >> My proposal is that whenever we seem to agree that some feature is > >> very rarely used and that it has very low impact and that there is an > >> easy way to recover, we classify it as "non-breaking change" and > >> remove it in the upcoming feature release. This will need to be > >> accompanied with documentation on how to recover, a warning message > >> when it happens and a deliberate statement by the community that we > >> should remove it. It can be a [LAZY CONSENSUS] thread. > >> > >> Generally something that community will be able to react to and oppose > >> (in devlist - not only in a PR) - also this way we will keep the > >> record of it in our archives, so that everyone can find out this was a > >> deliberate decision and what were the reasons for assessing that this > >> change is not risky to happen. > >> > >> If we agree to that, I am super happy to document it in our policies > >> in README as a way how we deal with such cases. > >> > >> Let me know what you think? Maybe others might have other proposals > >> what should be our policy for such non-obvious cases. > >> > >> J.
