Package API compatibility and guix package variable names

[Danny Milosavljevic <dannym@scratchpost.org>]

> > Shouldn't this be allegro-5 since there is already an allegro-4?  
> 
> I want the “allegro” variable to simply hold the latest version of
> allegro.  If ever there’s a need to clarify (e.g. because we need to
> keep around the last of the 5.x series when 6.x comes out) we can change
> the name then.  As far as I can see that’s been our approach for some
> other packages, too, most prominently “python”.

In my humble opinion it would best if there was an "allego-5.0" and an "allegro" variable, with the "allegro" variable not being referenced by any other package (they would reference "allegro-5.0" instead - or whatever major API version they need, for example "allegro-5.2").

This way we wouldn't have to update half of all package specs after they break just because a new incompatible version came out.

I think the way it was done for Python3 in Guix is wrong. On the other hand, the way it was done for Python2 in Guix was exactly right.

What happens when a new (incompatible) Python4 comes out? Patch all the Python modules package specs there are? The only reason we can get away with it for Python is because they only do breaking change in the language every five years.

This is something Debian got right - have the (API) version as suffix as part of the name.

The "allegro" metapackage is purely a user convenience (of questionable benefit).

If something becomes incompatible, its name should change.