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(a)physik.fu-berlin.de