Update database-erd-ref.rst

[RNHTTR]

The language as is seems to suggest that the database isn't backwards compatible; it should be backwards compatible, but it nonetheless probably shouldn't be directly accessed.

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[potiuk]

The language as is seems to suggest that the database isn't backwards compatible; it should be backwards compatible, but it nonetheless probably shouldn't be directly accessed.

Because that's what it is. We WANT to make backwards incompatible DB changes in the future (sometimes even in patchlevel releases). This is a clear intention we have.

It was intentional and very clear and strong statement that you absolutely should not rely on database structure. We might decide to drop a field or rename it at any time. And we want to be very clear about it.

This is also very clearly explained in the new page (that will be up in 2.6) that clearly explains what is (and what is not) public API interface that you can rely on - and the Database Structure is very clearly and specifically put in the "do not rely on it".

Why do you think it should not be clearly spelled out?

[potiuk]

Waiting for explanaation why the idea is to remove the "backwards incompatible" wording even if we actually want to be sometimes backwards incompatible with the database.

[RNHTTR]

I thought all Airflow components in a particular major release were more or less protected by semver. If the database schema is not necessarily protected by semver, does it make sense to add a caveat to https://airflow.apache.org/docs/apache-airflow/stable/release-process.html to indicate as much?

[potiuk]

I thought all Airflow components in a particular major release were more or less protected by semver. If the database schema is not necessarily protected by semver, does it make sense to add a caveat to https://airflow.apache.org/docs/apache-airflow/stable/release-process.html to indicate as much?

This is exactly what https://github.com/apache/airflow/blob/main/docs/apache-airflow/public-airflow-interface.rst is addressing - it explains what IS and waht IS NOT covered by our intent of backwards compatibility. Database had never been intended to be backwards compatible, we just never clearly stated it.

In general it is impossible to keep "ideal backwards comatibility" because no such thing exists. As extensively discussed in this devlist thread: https://lists.apache.org/thread/1by8ko8jrrp1xwxt5781bwn2tokxjodl, very nicely explained by Hyrum's Law and very succintly explained by this XKCD comic:

So with https://github.com/apache/airflow/blob/main/docs/apache-airflow/public-airflow-interface.rst we will attempt to explain what is supposed to be seen as "Public interface of Airflow" and what is not.

[RNHTTR]

There's an xkcd for everything!