Fedora and Fedora Legacy package versioning schemes

[Warren Togami]

Thank you for your well written proposal.

Axel Thimm wrote:
> Defining the problem domain for Fedora Legacy:
> ==============================================
> 
> a) We need a versioning scheme that ensures upgradability without
>    obfuscating too much the VR scheme.
> b) It should be possible to use the same sources/patches/specfiles with
>    macro controlled differences
> c) It should work with older rpm versions, e.g. don't let rpm compare
>    numbers with letters.
> 

a + b are perfectly valid, but I see no reason to continue to support 
the ugly behavior of c, and here's why:

1) jbj has long indicated that he wishes all distributions to use the 
same upgraded version of rpm in order to simplify maintenance.
2) Fedora Legacy is the time to FORCE everyone to upgrade RPM if they 
wish to continue to use the repository.  This means that we will be able 
to avoid a lot of unpredictable behavior (#1) in older versions of rpm, 
making Legacy distributions easier to support in the long term.
3) RH 8.0 Psyche rpm *needs* to be upgraded anyway because the default 
rpm is too broken to use.

(Read the bottom of this message for a summary of my %{release} naming 
proposal.)

> The easiest way to achieve a) and b) is to have
> 
> 	    Release: 4_%{disttag}
> 
> in the specfile and let %{disttag} expand to values in the right
> rpm-order for the given distributions.
> 
> A proposal on the fedora.us side is to allow rpm to compare "rh9"
> versus "1", which under newer rpms will resolve as older, but which is
> not the case for RH7.x (possibly even stock RH8.0, but I may be
> mistaken). There are updated rpm rpms fixing this issue, but they are
> neither available via RHN, nor can Fedora Legacy assume that those
> rpms are available on the system to be upgraded.
> 
> Therefore it is far better to compare numbers only with rpm.
> 
> So we need a versioning scheme f that numerically sorts
> 
>  ... < f("7.3") < f("8.0") < f("9") < f("1") < ...
> 
> Possible solutions:
> ===================
> 
> a) Call _internally_ the next release ("Fedora [Core] 1") "RawHide 10"
>    or "RawHide 9.1". It looks compatible with RH's policy and would
>    allow for tags like "rh10" to complete the above scheme.
> 

-1
Too confusing to have different numbers and names in different places.

> b) Drop upgradability withing Fedora Legacy from RHL to FC/FDR.
> 

-999
We should always maintain upgradability between distributions, and 
Fedora will strengthen this and prevent problems by stricter packaging 
standards than those enforced by RH internally in the past.  There is 
currently absolutely no reason to break upgradability.

> c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" <
>    "number" idiom.

-1

> 
> d) Use tags with something larger than "rh", e.g. "tfp" ("The Fedora
>    Project")

-500
The whole reason why we had those dist tags was because fedora.us (or 
freshrpms, or dag, or axel, etc.) were not official repositories.  Now 
Fedora is official, so I believe we can drop this ugliness that makes 
the package filename unnecessarily longer.

> 
> X) Your suggestion here.
> 
> It is important to have Red Hat's consent on any sollution, as well as
> a common versioning scheme across repositories of different
> maintainers to allow for properly formulating cross-repository
> dependencies and having easy identification by end users.
> 
> Optional good-to-have semantics:
> ================================
> o Use the same versioning for Fedora.
> 
>   It would be good to have a scheme applicable to both Fedora Legacy
>   as well as Fedora (current release). That way Fedora releases could
>   automatically become Fedora Legacy without rebuilding and
>   re-versioning.
> 

+1

> o Use the same versioning for RawHide/Betas.
> 
>   This would help building more often for RawHide. E.g. the following
>   scheme could be used until now:
> 
> 	 foo-1.2.3-4_rh8.0
> 	 foo-1.2.3-4_rh8.0.93 (beta)
> 	 foo-1.2.3-4_rh8.0.94.20030325 (rawhide)
> 	 foo-1.2.3-4_rh9 (release)
> 

+1
I dislike your specific examples that contain "rh", but the numbers I 
fully agree.

Warren's Release Naming Proposal (draft 1)
==========================================
All distributions in Fedora Legacy must upgrade to the latest version of 
rpm for that distribution.

%{release} name structure
-------------------------
X.%{non-numeric version}.%{distrel}

	X
RPM package release number, always increments with every update, even  a 
rebuild.
	%{non-numeric version}
Non-numeric characters at the end of upstream's %{version}.  Since 
%{version} must (almost) never contain non-numeric characters in order 
to avoid the Epoch treadmill (like mozilla package), the non-numeric 
portion can optionally be contained within the %{release} tag after the 
release number.
Examples:
mozilla-1.5-5.rc2
foobar-2.0-7.cvs20031005

%{distrel} Upgrade Path from fedora.us
--------------------------------------
0.fdr.X.rh80 -> 0.fdr.X.rh90 -> 0.fdr.X.0.94 -> 0.94 -> 1

fedora.us currently has an even longer "0.fdr.X" prepended before the 
suggested fedora.redhat.com scheme.  Thus absolutely anything containing 
numbers in the second glob will "win" against "fdr".

Examples:
foobar-1.5-6.rc3_1.9.2 (Fedora Core 1.92 beta)
foobar-1.5-6.rc3_1     (Fedora Core 1)
foobar-1.5-6.rc3_0.9.4 (Fedora Core 0.94)
foobar-1.5-6.rc3_0.8   (RHL 8.0 Psyche)
foobar-1.5-6.rc3_0.7.3 (RHL 7.3)

Note that I used "_" instead of "." in this particular example.  Either 
of them would work.  The former would be a clearer seperator between the 
%{distrel} and the rest of the tag, while the latter is slightly easier 
to type.  I personally don't care which one is used.  Opinions?

Warren