gnomechecker: Don't consider 3.odd unstable

[A6GibKm]

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.

[wjt]

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.

[A6GibKm]

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.

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.

[wjt]

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.

[wjt]

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 :(

[A6GibKm]

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.

[wjt]

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.

See #436 for a request to adjust the current rules and an example of a module that uses the older scheme: VTE.

[A6GibKm]

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).