Warren's Package Naming Proposal - Revision 1

[Nils Philippsen]

On Fri, 2003-10-31 at 18:00, Michael Schwendt wrote:
> On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
[...]
> > > Are there cases where rpm would consider imap-2000a as older than 
> > > imap-2000?
> > > 
> > > jbj?
> > >
> > 
> > Err... you are completely right about it not being necessary in the 
> > post-release case.  I am not sure why our fedora.us policy retained that 
> > even though it was unnecessary for all these months.  The way I 
> > understand the older version of rpm broken rpmvercmp behavior, this 
> > wouldn't be a problem with those versions too.
> 
> * To be able to go back from 2.1.7a to a patched 2.1.7 in case the
>   2.1.7a post-release "fix" turns out to cause side-effects.

Hmm I'm not sure if I buy that -- extrapolating form that, one should
also be able to go back from 2.1.8 to 2.1.7 in case the new version
turns out to cause side-effects (without any "--oldpackages" stuff or
that point is moot). We could also set the version to "1" for all
packages and use only serial numbers for releases -- that way updating
always works ;-).

I think the version should always be the upstream version where these
are not incompatible with RPM version comparisons and real version
numbers (and not CVS dates or the like because they may be substituted
with real version numbers which are likley less RPM wise) and (optional)
characters represent newer patch levels (and not prereleases). If that
version number contains dashes, replacing them with underscores might be
necessary.

> * Consistency above all.

Care to explain that one? Of course the idea I have about versioning
seems most consistent to me but I'm sure you can shed some light on why
version numbers differing from upstream are more consistent ;-).

> * The road of least surprise (with regard to upstream versioning).

That's what I want.

> * To help avoid that users think foo-1.0a would be an unstable alpha
>   version, when in fact it is a post-release patch-level.

I do not think that is the purpose of an RPM version tag. It exists so
the user knows that this is the upstream version number-- how else would
a user be able to submit bug reports upstream if he cannot supply the
real version number/string/whatever. If users interpret version strings
like "1.0a" as an alpha version when they're not -- well, that's tough
luck but nothing that should be worked around by some RPM version
trickeries.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031101/6e82cc66/attachment.sig>