[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Warren's Package Naming Proposal - Revision 2

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]