mesonbuild
Can make deprecations into hard errors based on version.
Add functionality to make deprecated features into hard errors "in the future". The basic idea is to give each deprecation a runway so that people can get their projects fixed with sufficient time, but also that the error will eventually happen without anyone having to remember to go back in the code and turn it into a hard error.
The default time should maybe be one year, so four releases? Dunno, comments welcome on that.
The example I converted was originally from 2022. People should have had that fixed by now.
I'm strongly in favor of using semver, people expect their old, deprecated features to keep working until we make a 2.0, and then there will likely be the expectation meson 1.x and 2.x can be installed at the same time, at least for a period while projects finally deal with their breakages.
Given, however, that if you don't set meson_version there wont be any deprecation warnings still, I think any talk of removing deprecated features is pre-mature
I agree that we don't want this change (unless the idea is to always use error_since='2.0').
In combination with https://github.com/mesonbuild/meson/pull/13617 we can just emit FeatureBroken instead.
I'm strongly in favor of using semver, people expect their old, deprecated features to keep working until we make a 2.0
For a library I would agree 100%. For an interpreted system like this, maybe we could consider a different approach. This is replicating what Python does. They decided not to have major breaking releases after 3, so all changes are done with a phased deprecation cycle. This was my proposal for such with the main point being very upfront about breaking changes and giving people specific deadlines (which are sufficiently far in the future) to do their conversions.
The more things are changed at once (via a large major version upgrade), the more inconvenient it is for end users, particularly distro packagers. Uploading a new major version that breaks many projects into Debian unstable, for example, is not fun.
I would not really call python a good model here, given that they start publishing beta releases of a version that fully removes the deprecated functionality at approximately the time that most people are first starting to install the version that began its deprecation.
Additionally,
They decided not to have major breaking releases after 3, so all changes are done with a phased deprecation cycle.
... this is just having major breaking releases more frequently, and then not annotating them as major breaking releases. The whole thing about "there will never be a python 4" is a common misquote. The actual rule is that they will never increment the major version number because it looks bad and makes people feel bad and gives people flashbacks to python 2->3.
By the way, about python 2->3, the problem there was not, and never was, that many things changed at once and people had to make many changes at once.
The problem was that python2 only supported A, and python3 only supported B, so there was no way to "do the right thing". Meson warns you about a bunch of stuff and how to do it better today, so a breaking change just means removing support for things that people were not supposed to do anyway. That is what a real breaking release should look like: cleaning up ancient cruft that people have been told for years not to do.
(And this is why python's phased deprecations are broken: they offer no time to fix things. Meson has run into this too: it was impossible to support all non-EOL versions of python with the same code, until someone decided to revert a deprecation and start supporting the "functional API".)
they start publishing beta releases of a version that fully removes the deprecated functionality at approximately the time that most people are first starting to install the version that began its deprecation.
This is of course bad and not something we should do regardless what the actual process ends up being.
I agree that the python model is infuriating. And a major thing I see is people making intentional decisions to keep very old versins of Meson supported because they want to build with the default toolchain in very old LTS releases, or because they want to ensure Muon compatibility, which currently has ~0.64 support. I really think it makes more sense to have a release process that looks like:
- Meson 1.LAST is released with features
- Meson 2.0 is released, it only removes deprecated features
- bug fixes are applied to 1.LAST and 2.x as applicable
- after 2.SOMETHING is released 1.LAST is declared basically as-is, and we move on.
This gives people a good experience with the whole process, and it should be possible to write Meson that will work with relatively recent versions of 1.x and 2.x
Yup. The simple and obvious idea I have for what to deprecate looks something like:
- we want to release 2.0
- take a look at which version of meson is packaged by debian oldstable (currently, bullseye: 0.56.2) and Ubuntu old-LTS (currently, 22.04 Jammy: 0.61.2)
- drop deprecated functionality where the solution is available in those LTSes (unrelated to which version the deprecation warning was added)
- tentatively: drop all FeatureBrokens since no one should have been using them ever anyway