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

Tue May 25 13:39:04 CEST 2004

Hi,

please comment on this, I believe that a common versioning scheme is
important. It can't be that difficult to formulate an acceptable
implementation. ;)

I think it all turns around defining acceptable disttags, the rest is
more or less straightened out by now. I think the "fc" and "el"
disttags are liked by everybody, one needs to have a
smaller-than-"fc1" disttag for RHL releases, which could be the
proposed "fc0.".

Even if it's "ablaubla" (still smaller than "fc"), it is important to
standardize it, and it has to be done by the repo maintainers. Note
that on fedora-devel the usage of disttags is still not accepted, so
we cannot ask for input on implementation there. :(

We have all Red Hat/Fedora players here, so let's show we can get a
common standard up and running.

On Fri, May 14, 2004 at 12:05:14PM +0200, Axel Thimm wrote:
> 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 :)

> _______________________________________________
> repo-coord mailing list
> repo-coord at atrpms.net
> http://lists.atrpms.net/mailman/listinfo/repo-coord

-- 
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/20040525/f5e33121/attachment.bin