On Sat, Mar 24, 2007 at 01:15:50PM +0100, Nicolas Mailhot wrote:
Le samedi 24 mars 2007 à 01:52 +0100, Axel Thimm a écrit :
On Fri, Mar 23, 2007 at 02:18:33PM -0700, Toshio Kuratomi wrote:
Our rule would be:: Does upstreams version have an alpha tag? If yes, use alphatag versioning.
The point is that we don't really want too many of the prereleases and therefore don't care about the (temporary) obfuscation that much (not that we could do anything better anyway).
But with "postreleases" it's quite different. openssl is a prominent example where people will be confused to see openssl-0.9.8-8.3.b.fc6 instead of what we currently have: openssl-0.9.8b-8.3.fc6.
IMHO people (both users and packagers) will be confused if we don't follow consistent rules. The "what if we can reasonably expect upstream to be sane" argument has been rejected for pre-releases
No, why do you say so? We are promoting upstream to use even/odd schemes or 1.2.99 schemes (for prereleases to 1.3).
If it plays well with rpm, why break it?
"But we've done differently in the past" is a weak argument. In the past we had incomplete BRs and broken EVR upgrade paths, we changed stuff to fix it, and people weren't confused.
Well, consider a dependency on openssl >= 0.9.8b. If the postrelease letter slides into the release then suddenly we need to know about build-ids in comparisons like >= 0.9.8-X.b.
Dependencies force us to leave the versioning rather uncumbered.
Lastly consistent rules means we can hope to built them in some future rpm version instead of relying on guidelines, now that rpm dev has resumed.
I don't think the rpmvercmp will ever change, no matter how active rpm development is. This is being discussed since rpm was born and the point is no matter how you try to adjust to upstream versioning some upstream authors will be clever enough to break any machine ordering scheme.