Kind request: Set release version to "10" (was: Retain upgrade paths)

[Axel Thimm]

Before this thread vanishes into nirvana:

I'd like to kindly request to set to release version to "10" or
something higher than "9.0.94".

It would neither hurt marketing goals, nor any technical issues, but
it helps a lot with 3rd party repos supporting more than just the
latest release. Embedding (rpm-)increasing tags into the package
release ensures sane upgrade paths (similar to some Red Hat errata
releases like the kernel rpms). If you have questions on the technical
background follow up the thread.

If there isn't any compelling reason for setting the release version
to "1", please consider helping 3rd party repos with a sane release
version. After all part of the new open source movement is to better
support external developers and packagers.

Thank you.

On Thu, Sep 25, 2003 at 01:39:08AM +0300, Axel Thimm wrote:
> This has not to do with fc isolated, but with the supporting 3rd party
> repos. It was discussed further up this thread, but I will rephrase
> with an example. There exist more than one repository building rpms
> for several RH releases (say RH7.3, 8.0 and 9). In order to ensure
> upgrade paths for the users of this repository the packages are being
> called
> 
>      foo-1.2.3-1.rh7.3.i386.rpm
>      foo-1.2.3-1.rh8.0.i386.rpm
>      foo-1.2.3-1.rh9.i386.rpm
> 
> or similar variations like omitting the "rh" etc. Upgrades from one RH
> release with enabled repo to another were thus safe.
> 
> Just to give more food for thought: How would you version a kernel
> based on the same sources released for RH 7.x,8.0,9 and now
> additionally fc?
> 
> 	kernel-2.4.22-1.2082.7.i686.rpm
> 	kernel-2.4.22-1.2082.8.i686.rpm
> 	kernel-2.4.22-1.2082.9.i686.rpm
> 	kernel-2.4.22-1.2082.0.94.i686.rpm
> 
> The latter looses. You either have to rethink the first three or
> version the last with something rpm-higher than "9". Or start epochin
> all such packages occuring on multiple releases, which for somerpeos
> means all of the carried packages.
-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20030930/886156c8/attachment.sig>