Kind request: Set release version to "10"

[Michael Schwendt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 6 Oct 2003 20:47:48 +0200, Axel Thimm wrote:

> > > > A few observations: In your repository I don't see a consistent
> > > > platform specific release tag scheme.
> > > 
> > > check the dates and the discussion on fedora.us in March/April (yes, I
> > > was once a fedora member).
> > 
> > Been there before I joined the fedora-devel at fedora.us list. Going
> > through list archives is a time-consuming process. I prefer
> > summaries of ready-to-use concepts which can be commented on as a
> > whole.
> > You don't answer why some of your packages have no distribution specific
> > release tag at all and why other packages override versions found in Red
> > Hat Linux.
> 
> What I wanted to say is that the versioning scheme evolved, partly on
> its own, partly in discussion within (the old) fedora. So when you
> find inconsistency in the repo you are seeing at different layers of
> history.

I fail to see that. Here's one of the packages for Shrike, which
was touched long after the disttag discussions:

  mplayer-0.90-18.athlon.rpm
  http://atrpms.physik.fu-berlin.de/dist/rh9/mplayer/mplayer-0.90-18.athlon.rpm?info

Or this one from July (0.9 = Shrike?):

  perl-DateManip-5.42-0.9.noarch.rpm
  http://atrpms.physik.fu-berlin.de/dist/rh9/perl-DateManip/perl-DateManip-5.42-0.9.noarch.rpm?info

Another one for Shrike, from the same period of time, but has a disttag:

  libapt-pkg-devel-0.5.5cnc6-34.rh9.at.i386.rpm
  http://atrpms.physik.fu-berlin.de/dist/rh9/apt/libapt-pkg-devel-0.5.5cnc6-34.rh9.at.i386.rpm?info

So much about consistency. There are more examples like that.
Back to the topic.

> > Continueing Fedora Core with Red Hat Linux specific release numbers
> > does not sound reasonable. It is like an implicit epoch.
> 
> OTOH you are right, but if the packages from the Fedora Project are to
> be related to Red Hat Linux ones (e.g. you want them to be rpm-newer),
> you need to come up with a compatible scheme.

Packages in Fedora Core 1 will be newer than any packages in Red Hat
Linux. Only a few cases (e.g. comps, maybe comps-extras,
redhat-release => fedora-release) need special treatment (probably an
increased epoch).

I understand that Red Hat have never supported an upgrade path from
installations other than Red Hat Linux. The Fedora Project is a new
thing. It doubt it changes history by treating old 3rd party
repositories for Red Hat Linux as if they had been official Fedora
Extras/Alternatives/Legacy repositories before. In other words, they
are unsupported. Starting with Fedora Core 1 you may need to implement
a compatible versioning scheme, i.e. bump the release versions or
vepochs (if any) of all your old packages before you put them into
your Fedora add-ons repository. As I've pointed out before, some of
your package versions conflict with Red Hat Linux anyway (e.g. bash,
perl-DateManip, mozilla).

> Did you check Warren's proposal on doing the reverse? E.g. instead of
> continuing RHL versioning into Fedora, one can back-continue Fedora
> guidelines to the past, e.g. treat RHL8.0 as Fedora Core 0.8.0.

Yes, sounds good. It's not the first time a "0." prefix is useful.

- -- 
Michael, who doesn't reply to top posts and complete quotes anymore.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/gchv0iMVcrivHFQRAslfAJ9Ot/0Jrg+idu3H9V6aAgfDaglXmgCeOTC1
Ar1JDanpiVcP03zzeURtaVc=
=TlhL
-----END PGP SIGNATURE-----