Due to the spotty release schedule it has become common practice to base ZDoom projects on devbuilds, essentially taking for granted that once a feature was in it was final.
I don't think I need to emphasize that many times this caused problems because the engine got stuck with features that got prematurely exposed and could not be removed again.
So I think it is time to actually define an official policy about this.
I do not plan to continue the ZDoom release schedule. My personal idea of this is to do more frequent releases, at least two minor revisions each year with point releases to address bugs in-between. I already did so with 2.3.1 and 2.3.2, both of these releases are based on 2.3.0 and only contain the actual bugfixes since the first release but not the newly added features.
For the master branch the devbuilds are based on this means that it may switch between two different development styles - feature implementation and release preparation. The current state is clearly feature implementation, and the nature of this means that I may decide on short notice that some code needs to be disabled or removed. I will announce once I switch to release preparation.
While it should be perfectly fine to develop a new project based on devbuilds, anyone doing so has to be prepared to make a change to their project, should such a breaking change happen in the engine. What should be avoided is to release a project to the public which requires a devbuild to run. In that case you should better wait until the next release, even if you have to wait for a few months with the release then. I can not and will not address problems that come from releasing a devbuild-based project if it breaks between its release and the next official version. Doing so would make it impossible to undo things that later turn out to be a hindrance to engine development.