[repo-coord] Re: Versioning proposal, please comment (was: disttag -- repotag)

[Axel Thimm]

Hi,

I think now most repos use indeed <truereleaseinfo><disttag><repotag>.
The only remaining question is which disttag scheme to use.

Given that all RHL releases are past EOL, I could imagine that
switching from the often used "rh" for RHL and "rhfc" for FC to "fc0."
for RHL and "fc" for FC would shift the obfuscation of the release
tags from FC to RHL.

Personally I'd go with any disttag starting with a letter and ending
with numbers, which are rpm sorted for RHL/FC and adopted by the
majority of repos. The rhfc idiom served its purpose very well (thanks
again, Nando!), but has hit political frontiers at Red Hat due to the
connotation of "rh" with "fc". Technically equivalent, but politically
probably acceptable (at least for the FC part) seems to be:

   fc0.7.3 < fc0.8.0 < fc0.9 < fc1 < fc1.90 < fc1.91 < fc1.92 < fc2

Or "fdr", "flp", "fp" instead of "fc", anything you suggest.

I know from previous discussions at fedora-devel, that even fedora.us
would be happy with such a scheme (at least half a year ago they would
have been), so we have a chance to get something homogenious! :)

So,

1) does anyone object to the usage of disttags at all?
2) would you be willing to switch to the scheme above, or suggest
   another technically equivalent scheme?

P.S. a technically equivalent scheme was already proposed by Matthias,
using something like "a.rh" and "b.fc" (the original proposal had
numbers instead of "a", "b", but numbers break), please search the
archives for distepochs. I would prefer renaming rhl to "fc0." (or
"fdr0."  etc.), and having "clean" disttags for at least FC.

On Fri, Mar 12, 2004 at 01:27:11PM +0100, Axel Thimm wrote:
> I am cutting this proposal into several steps, with the ones moved to
> the top, where most agreement has been found:
> 
> 1) rpm release tags should segmented into
>    <truereleaseinfo><disttag><repotag>
> 
>    <truereleaseinfo> can contain
>    o vendor_subvendor constructs (i.e. a 3rd party package
>      extending/bugfixing a Red Hat package foo-1.2.3-4 could be
>      starting with foo-1.2.3-4_1..., or the 0-prefix tricks etc.)
>    o extra version information that should belong to the version tag,
>      but is moved to the release tag to ensure proper upgrade paths
>      (for example upstream versioning of foo-1.2.3pre4).
>    NOTE: The above are examples, the syntax is not discussed here,
>    please let it be discussed in the next round to avoid
>    overcomplications).
> 
>    <disttag> should be an rpm-ordered entity that ensures
>    upgradeability for build carrying the same <truereleaseinfo>.
> 
>    <repotag> is an optional identification string, which the repo
>    maintainers may choose to add to their crafted packages.
> 
> I believe all should agree up to here.
> 
> 2) <disttag>s should be shielded from being mixed in rpm comparisons
>    with the <truereleaseinfo>. For avoiding mixing of
>    <truereleaseinfo> numerical segments with the <disttag>, the
>    <disttag> should start with letters (Two reasons: Usually the
>    <truereleaseinfo> should start and end with numeric segments, and
>    letter segments are considered lower than numeric for rpm version
>    younger than 15 months, in case the tags do get eventually mixed)
> 
> I also believe we persuaded everyone here that this is neccessary
> 
> 3) <disttags> should be setup as <distid><distversion> which <distid>
>    a constant letter string like "rh", "mdk", "lsb", "common", ... and
>    <distversion> the version of the distribution (not for "common" of
>    course). As long as "universality" (e.g. not-RH centric) of the
>    scheme does not hurt, we should consider it.
> 
> 4) Suggestions for implementations for Red Hat Linux and Fedora Core
>    series
> 
>    a) rh7.3, rh8.0, rh9, rhfc1, rhfc1.90, rhfc2, ...
>    b) fc0.7.3, fc0.8.0, fc0.9, fc1, fc1.90, fc2, ...
> 
> As the maintainer of ATrpms, I would "vote" for a), since this is what
> 2/3 of the repos already run (including ATrpms). If the majority
> prefers b) or another scheme ATrpms would switch. 
> 
> 5) Specfile should contain somthing like (your suggestions are welcome)
> 
>    Release: 4%{?disttag}%{?repotag}
> 
>    and the values for the above macros should be injected from outside
>    the specfile (/etc/rpm/macros, .rpmmacros or --define). This will
>    allow the same specfile to be shared among different repo, and used
>    by different distros, e.g. could be embedded in upstream tarballs.
> 
> Of course I wish that all of you respond with "all points agreed", but
> today is not Xmas ;)
> 
> Next round about versioning could address
> o structure of <truereleaseinfo>
> o versioning of kernel modules
> 
> But, please don't discuss these yet before we get the above settled :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20040514/6143ade8/attachment.bin