On Sun, 9 Nov 2003, Warren Togami wrote:
> PLEASE, take a look at dpkg's and apt-get's way of
handling pre-release
> versions, I really do think that should be used in rpm-based distros
> too.
> The idea is to introduce a character, namely '~' (tilde), which is
> sorted specially: in comparison it comes before anything else.
>
> This way, you can get ordering like this:
>
> 1.0~alpha1 < 1.0~alpha2 < 1.0~beta < 1.0 < 1.0a < 1.0b
> 1.0~pre1 < 1.0~rc1 < 1.0 < 1.0.1 < 1.0.2
> ... and so on.
>
> Hope you got the point.
>
> I know it should be implemented in rpm, and this is not a trivial move,
> but please do think about it. It will make all these
> pre-release-versioning nightmares go away.
>
Interesting concept. This is the first time I heard of this. It would
take a serious amount of analysis to figure out if this can be
implemented in rpm in a way that wont break backward compatibility.
There is also the question of if we *want* to do this or not. Much
discussion is needed. In any case it would take a long time to analyze
if we want to implement this in rpm and all related tools or not. I
currently have no opinion on this matter because I don't know enough
about it.
In the mean time this package naming scheme describes how to properly
avoid packaging problems in the rpm of today.
One problem is that the word "pre", or "rc" or others are not
used consistently between software projects.
Some use "pre" like:
Prerelease: 2.7.95pre1 (prerelease of version 2.8, or perhaps 2.7.96)
Release: 2.8
Others use "pre" like:
Prerelease: 2.8pre1 (Prerelease of version 2.8)
Release: 2.8
It's possible that one project does it like above, and another
does it like:
Release: 2.8
Prerelease: 2.8pre1 (Prerelease of version 2.9)
Both types of versioning are out there. There is no way of
knowing wether the "pre" part is newer or older based solely upon
alphanumeric comparison, because different projects use the
keyword differently. The only way is by human interpretation.
As such, having the software consistently use one single
interpretation is the best solution, as you know 50% of the
projects out there will work without thinking about it. Then
it's only the other 50% that need manual developer attention, and
that can't be voided as it isn't possible to know which of the
two interpretations is intended via software alone.
--
Mike A. Harris
ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat