flathub-infra
gnomechecker: Don't consider 3.odd unstable
There is only a handful of modules using the older version scheming.
The version scheme consisted declaring a release with numbering 3.x stable if 3 was even and odd otherwise. This versioning scheme was dropped by most modules around GNOME 40.
For context, this causes multiple false positives with modules like tracker who have a major version equal to three but do not follow the old numbering scheme.
cc @fosero, @ebassi.
As it stands, for e.g. tracker you can set stable-only to false and receive updates.
But with this proposed change, apps that use modules that do follow the minor-odd-is-unstable convention have no way to ignore unstable releases. My clone of all of Flathub is a bit out of date but one example is glibmm and friends which are used by a fair number of apps.
As it stands, for e.g. tracker you can set
stable-onlytofalseand receive updates.But with this proposed change, apps that use modules that do follow the minor-odd-is-unstable convention have no way to ignore unstable releases. My clone of all of Flathub is a bit out of date but one example is
glibmmand friends which are used by a fair number of apps.
I need to debug this further, at this point every single we have to flip around the value of stable-only to fix this issue.
Maybe a new version-scheme property with string values e.g. odd-minor-is-unstable or alpha-beta-rc-tags (just ideas off the top of my head) defaulting to the newer model. Then when tracking a project that does use the old scheme the odd-minor-is-unstable mode could be enabled but the default would work for the prevailing convention.
It would be even better if there were something in the GNOME release "API" that could be used to determine what the latest stable/unstable version is of a project and/or whether any given release is stable or not, rather than matching on version numbers, but I don't think there is :(
There is not, and then again, the modules that didn't upgrade to the newer version schedule last time are even less likely to migrate to this new api.
Maybe a new
version-schemeproperty with string values e.g.odd-minor-is-unstableoralpha-beta-rc-tags(just ideas off the top of my head) defaulting to the newer model. Then when tracking a project that does use the old scheme theodd-minor-is-unstablemode could be enabled but the default would work for the prevailing convention.
See https://github.com/flathub-infra/flatpak-external-data-checker/issues/436 for a request to adjust the current rules and an example of a module that uses the older scheme: VTE.
Thanks for the link. With the "older scheme" I refer to packages with a major version of 3 (and using odd/even to denote stability).
Superseded by https://github.com/flathub-infra/flatpak-external-data-checker/pull/453.