Add mechanism to deprecate a wrap in releases.json

[bgilbert]

We have two formally-deprecated wraps, json and onqtam-doctest, plus a wrap luajit that doesn't perform formal releases and should not have been accepted. Add a mechanism for declaring these in releases.json so Meson can warn about it.

[bgilbert]

Added a deprecation for pcre, which has been replaced upstream with pcre2.

[bgilbert]

Added a distinction between replacement (an API-compatible replacement, where Meson could in principle automatically switch to the new wrap) and successor (well-defined but non-API-compatible replacement).

[bgilbert]

Any objections?

[neheb]

I think the catch wrap should be as well.

[eli-schwartz]

I don't under the purpose of "successor". It's for cases where the upstream project has made API/ABI incompatible major version changes, apparently, and the WrapDB wants to... what? Warn people that they'd be better off porting to the newer but dramatically different APIs?

For the stated example brought as a rationale for adding this metadata marker, pcre is "end of the line" software upstream in favor of pcre2, but enough years later that I shudder to think about it... half the world hasn't actually migrated because migrating is complicated (and even the pcre developer no longer remembers what the things to watch out for during a port are, because the porting documentation was never written down and existed only in a couple people's heads).

I would very much say, that while there will never be a new upstream tag for pcre, we would/should consider the wrap itself supported in the sense that we'd accept updates to the meson.build files. And from a Meson perspective I'm opposed to having meson wrap [...] emit warnings if a project makes use of pcre (1) via wrap files.

The doctest / json etc wraps are different since we're dealing with renamed wraps and really the only useful metadata property is the fact that the wrap entry has been redirected to a new name. So this PR does seem to handle that as expected.

Stuff like luajit is interesting and I'm not sure what the best way to deal with it is. Upstream luajit failing to release notwithstanding, the entire world actually does use luajit and package it for distros etc and so forth, so if it's good enough for stable distros I do hear the argument that it should be accepted in the WrapDB. It is ugly though, there is no denying it.

[bgilbert]

I don't under the purpose of "successor". It's for cases where the upstream project has made API/ABI incompatible major version changes, apparently, and the WrapDB wants to... what? Warn people that they'd be better off porting to the newer but dramatically different APIs?

Yes. It's work they need to do eventually, whether anyone likes it or not. The first version of this PR implied that reason should be used for this case, but a) it's common enough for an upstream to designate a successor project and it's easy to provide machine-readable metadata for that, and b) a contributor might miss this subtlety and use replacement for non-drop-in replacements, which wouldn't be appropriate if Meson someday adds auto-redirection for replacement wraps.

catch → catch2 would also be a successor because catch2 had API breaks in 3.0. Maybe someday we'd add termbox → termbox2 as well.

I would very much say, that while there will never be a new upstream tag for pcre, we would/should consider the wrap itself supported in the sense that we'd accept updates to the meson.build files.

Our responsibility for it has to end at some point, especially since we can't have downstream patches by policy. However, we could have sanity checks permit wrap updates in the successor case, which would still give us the warning, hide the project from searches, etc.

Stuff like luajit is interesting and I'm not sure what the best way to deal with it is. Upstream luajit failing to release notwithstanding, the entire world actually does use luajit and package it for distros etc and so forth, so if it's good enough for stable distros I do hear the argument that it should be accepted in the WrapDB. It is ugly though, there is no denying it.

Yeah, it's not great. If we actually want to support LuaJIT I can remove the deprecation for it. My main concern is that upstream doesn't seem to be well-behaved (previous discussion) and we don't have the capacity for the level of maintenance upstream has decided to expect.

[bgilbert]

Looking around a bit, Fedora deprecated pcre but hasn't removed it yet, Debian removed it in current stable, Ubuntu still has it (tracker).

[eli-schwartz]

That doesn't change my stance -- meson wrap [...] will not (accept PRs to) tell people to port their source code in order to avoid specific wraps.

[bgilbert]

Okay, why not though? What's the downside of warning developers that they need to do some maintenance to, e.g. in this case, stay in security support?

[eli-schwartz]

There are already quite a few ways for projects to become aware of this, and I don't really think that the build system needs to be responsible for tracking lists of deprecated software. It provides an inconsistent experience between wraps and system dependencies. The message primarily targets users building the software (who can't do anything about it), rather than developers writing the software (who can). It breaks building with --fatal-meson-warnings without providing good value for the cost.

Regarding the documentation for de-listing deprecated wraps, it is inconsistent to list old versions of a single wrap name (that are all deprecated) but not list old major versions of pcre, just because the two can be installed in parallel. Although eliding renamed wraps seems reasonable.

[bgilbert]

Okay. That leaves us with the two cases where WrapDB uniquely has information about a wrap: renamed wraps (which seems uncontroversial) and wraps we don't intend to maintain anymore. Do you object to showing a warning in the latter case?

I agree that if the website lists old wrap versions it should also list unmaintained wraps; we could maybe add e.g. (unmaintained).

So, re the current set of wraps:
json and onqtam-doctest → rename
catch → renaming isn't a 100% fit because of the 3.x API break, but seems more correct than marking it unmaintained
pcre → do not deprecate
luajit → we should reach a decision to actually maintain this or to deprecate it; @jpakkane opposed updating it in #1632