So with GNOME 40, almost all applications moved away from unstable odd version numbers and switched to .alpha, .beta, .rc instead. However, most GNOME libraries ignored this switch, as not many libraries were originally following GNOME versioning in the first place (which is fine). Problem is, even/odd versioning is confusing and it’s worst for libraries, where some libraries may follow the practice, some don’t, and for a few it can even be unclear!
My suggestion is to adopt alpha/beta/rc versioning and get rid of odd versions completely. Having multiple numbered alpha releases and multiple numbered beta releases is fine if desired.
The downside of removing even/odd versioning is the third component of your FOO_CHECK_VERSION macro will no longer be usable for unstable releases, which may be potentially annoying. And you’ll need a couple build system adjustments. But I think the advantage of avoiding unstable version confusion outweighs the cost.
Opinions welcome. Maintainers, nobody is going to force you to adopt a different versioning scheme, but it’s a suggestion to consider.
When distributors package a module, do they all look at ftp-release-list ? Or do they use a system that polls the server to see if new versions are available?
It’s for clearly and uniformly describe what is the versioning scheme and schedule for the module (even/odd, or alpha/beta/rc ; follow GNOME schedule, or release when it’s ready).
ftp-release-list shows the NEWS entry. I’ve seen some module maintainers writing a sentence at the beginning of each entry: “this is an unstable/development version, […]”.
So, how best to describe and announce to distributors those pieces of information? With the *.doap file? Then aggregate these infos for all the modules, somewhere (just a simple web page)?
In general I agree, I think it would be a good idea to change the versioning scheme of libs to alpha/beta/rc. But it’s something in transition in GNOME, it’s not done for all modules at once, so something that would ease the work of packagers would be useful in my opinion, but of course it would need some work to setup this.
but to show versioning schemes and release schedules (release schedules can be different than the GNOME one for some dependencies or for things part of the World/).
Then (a bit unrelated), but it is worthwhile to look at the dependencies from time to time if they can be simplified (some deps to remove).
The simple page that I had in mind can also be created manually, since the content doesn’t change often. And could include also whether the library has a guaranteed stable API. (this would be useful beyond the transition period).
Ok, didn’t know about this. I suppose that other distributions make use of it.
The page to create that I had in mind would be less useful then, since it already exists in some shape (but not for whether a library has API stability guarantees, i.e. where to be cautious).