From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Schmidt <mail_ben_schmidt@yahoo.com.au>
Date: Thu, 15 Mar 2012 11:51:02 +0000
Subject: Re: [mlmmj] Mlmmj 1.2.18a1 released
Message-Id: <4F61D7A6.10904@yahoo.com.au>
List-Id: <mlmmj.mlmmj.org>
References: <4F5E32B9.6090908@yahoo.com.au>
In-Reply-To: <4F5E32B9.6090908@yahoo.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: mlmmj@mlmmj.org

>>>> An alpha release for the upcoming Mlmmj 1.2.18 has been published.
>
> Works fine so far. Didn't notice any regression.

Thanks a lot for the feedback.

>>> Later, if you publish 1.2.18.0, it's going to be considered smaller
>>> than 1.2.18a1

In trying to figure out a better scheme, I disproved it for Debian:

$ dpkg --compare-versions 1.2.18a1 lt 1.2.18.0 && echo YES || echo NO
YES

It's a problem if the final .0 is omitted:

$ dpkg --compare-versions 1.2.18a1 lt 1.2.18 && echo YES || echo NO
NO

That is what I would have done, but due to this issue, I'm happy enough
to include the final .0 as occasionally we do have three-point releases
anyway, and this may be the best solution.

> Yeah, this is used by several projects and shouldn't cause any
> trouble... It works under Arch Linux (pacman, which uses a version
> comparison algorithm ripped off from RPM):
>
>      $ vercmp 1.2.17.0 1.2.18.0
>      -1
>      $ vercmp 1.2.18.0a1 1.2.18.0
>      -1

What about

$ vercmp 1.2.18a1 1.2.18.0

?

Smiles,

Ben.