I like the general idea of experimental API, although Carl and Aymeric's notes
are important: If we do this, we need to very picky in its use, or else it
just becomes an easy route to avoid committment. In particular, there should
be a hard-and-fast rule that nothing should be made an "experimental API" if
it can just be done outside of core.
For the example given -- backend API -- I think that, again, Carl and Aymeric
are right; the examples I have more in mind for this are user-facing ORM
features like the expressions, or custom lookups. I think it might be better
to let people play with them more, in a released version, before setting the
APIs in concrete.
With that in mind, I would also reconsider adding a silent warning when the
features are used -- because, if they are for general use (as opposed to the
use of, say, 3rd-party backend developers) then there's a significant use-case
where the person who would use the API is not the person who configures the
warnings on the CI.
My 2 cents,
Shai.
