Questions about versioning of external dependencies

[mgrojo]

After adapting ASFML to the latest release of CSFML (version 2.5.2), I wonder about two things:

• Should I make an Alire release now or wait. Since this release is new, it is not yet in most distributions. It is in Arch Linux, but last time we looked at it, it was broken. But at the same time, the users can provide their local versions for a crate, so maybe this is not enough reason to postpone the Alire relase.
• If I choose to release in Alire, how should I set the version requirement? It seems CSFML has not followed semantic versioning, and the third number is not compatible. Ok, they've only fixed things, but since it is a binding, what they have fixed is the API, breaking compatibility in some place. On the other hand, I see that my distribution, Ubuntu, currently uses this versioning scheme: 2.5-1.1. Then I guess a future CSFML package will be named 2.5-2.x. On the other hand, Fedora seems to use the three dotted numbers (2.5.2) as upstream. Then a requirement "^2.5.2" won't work on Ubuntu, even when they release that version. Or would they be forced to use 2.5.2 due to compatibility policies? I suppose Alire does not provide different versioning schemes for external crates as it provides for the different naming schemes.
  • If I release now a version and in the pull request remove all the distributions that currently don't work, would I be able later to update this very same crate release when the distributions start to include CSFML-2.5.2?

[mosteo]

The external detectors try to get the upstream version when this is clear from the distro versioning practices (and I thought that was the case for all the supported ones). If not that's a bug on our side. So, bottom line, you should rely on the upstream version. Please let me know if you see some discrepancy between distros here.

That said, if some distro isn't playing nice, you can have conditional dependencies per distro on asfml, and use what fits best.

As for your last question, yes, updating metadata of a release in a non-code-changing, non-breaking way is something we allow (and welcome, if it's to fix things).