Usually, when discussing stability of the APIs (in a broad sense; databases and programming languages are also APIs), only two states are mentioned:

• an API is stable if there’s a promise that all future changes would be backwards compatible
• otherwise, it is unstable

This is reflected in, e.g, SemVer: before 1.0, anything goes, after 1.0 you only allow to break API if you bump major version.

I think the actual situation in the real world is a bit more nuanced than that.
In addition to clearly stable or clearly unstable, there’s often a poorly defined third category.
It often manifests as either:

• some technically non-stable version of the project (e.g., 0.2) becoming widely used and de facto stable
• some minor but technically breaking quietly slipping