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.
