This is the mail archive of the
mailing list for the Cygwin project.
Re: upset, genini: different version ordering
- From: Yaakov Selkowitz <yselkowitz at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 19 Oct 2015 12:28:41 -0500
- Subject: Re: upset, genini: different version ordering
- Authentication-results: sourceware.org; auth=none
- References: <87380i671e dot fsf at Rainer dot invalid> <55AD399D dot 7020001 at dronecode dot org dot uk> <5617C006 dot 7070908 at dronecode dot org dot uk> <20151019154236 dot GC18989 at calimero dot vinschen dot de> <87mvvehj3t dot fsf at Rainer dot invalid>
On Mon, 2015-10-19 at 19:19 +0200, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> I don't really want to spend effort on unravelling the complexities of the
> >> sorting that upset does, since I don't think it's worth keeping, and we
> >> should switch to a scheme which can be described in a paragraph,
> >> e.g. the scheme used by setup and RPM:
> >> Compare contiguous chunks of digits or non-digits.
> >> Non-digit chunks sort before digit chunks.
> >> Digit chunks sort numerically, non-digit chunks sort lexicographically.
> >> The version with a suffix remaining is the greater
> > Sounds right to me. If we can make the version handling equivalent to
> > RPM's, it would be really helpful, I think.
> While that is by far the most widespread system thanks to GNU/Linux, it
> is not the only one. Emacs uses a very similar scheme, but treats
> 1.0alpha < 1.0beta < 1.0pre < 1.0 == 1.0.0 == 220.127.116.11
> which sort of makes sense, but can't be handled by a simple
> lexicographical sort. You also have to be able to ignore non-sortable
> components like Git commits. All of this is already existing in Cygwin,
> so unless you're proposing that these version numbers should all be
> changed to conform to the one true version scheme (which will be painful
> in other ways), then I still propose that we need to make the version
> ordering switchable.
Switchable versioning schemes means that code has to be multiplied in
both setup and upset, which is just asking for problems. There needs to
be one single versioning scheme, period, and using RPM's makes sense.
As for existing packages with nonconforming version numbers, yes, they
will need to be switched whenever they are next updated. Adding an
"Epoch" equivalent (which is anyways needed for other cases) would solve