On Tue, Dec 20, 2016 at 09:50:42AM +0100, SZEDER Gábor wrote: > > It just seems like the whole thing would conceptually easier if we > > pre-parsed the versions into a sequence of elements, then the comparison > > between any two elements would just walk that sequence. The benefit > > there is that you can implement whatever rules you like for the parsing > > (like "prefer longer suffixes to shorter"), but you know the comparison > > will always be consistent. > > I considered parsing tagnames into prefix, version number and suffix, > and then work from that, but decided against it. > > versioncmp() is taken from glibc, so I assume that it's thoroughly > tested, even in corner cases (e.g. multiple leading zeros). > Furthermore, I think it's a good thing that by default (i.e. without > suffix reordering) our version sort orders the same way as glibc's > version sort does. Introducing a different algorithm would risk bugs > in the more subtle cases. Fair enough. If it's working, I agree there is risk in changing things. And if you're willing to deal with the bugs, then I'm happy to stand back. :) > Then there are all the weird release suffixes out there, and I didn't > want to decide on a policy for splitting them sanely; don't know > whether there exist any universal rules for this splitting at > all. E.g. one of the packages here has the following version (let's > ignore the fact that because of the '~' this is an invalid refname in > git): I have a hunch that any policy you'd have to set for splitting is going to end up becoming a policy you'll have to use when comparing (or you risk violating the transitivity of your comparison function). But that's just a hunch, not a proof. Again, I'm happy to defer to you if you're the one working on it. -Peff