terminology and the hierarchy of releases

[Robert P. J. Day]

On Mon, 9 Feb 2004, Jay Turner wrote:

> On Mon, Feb 09, 2004 at 10:46:25AM -0500, Robert P. J. Day wrote:
> > 
> >   1) base (the actual official release)
> >   2) updates (approved)
> >   3) proposed updates (a.k.a. updates/testing)
> >   4) development (cutting edge)
...
> I think the truth lies somewhere in the middle.  According to the way
> things have gone for 5 years (not saying they will always go this way, but
> 5 years is a pretty good sample) the versions of everything down the list
> should increase or at least be the same:
> 
> base <= updates <= proposed updates <= development

sure, it's obvious that that's the way things have gone so far. but it's
theoretically possible that a new release may have to back off of a
previous official update RPM, no?  (or, even worse, back off of a base
release RPM).  although that would cause real ugliness, i would think --
what would it mean to "upgrade" from one release to the next if some RPM
actually dropped in version number?  that just hurts to think about. so
i'm going to stop thinking about it.

> Digging a little deeper, here's what Seth might have been trying to get at
> (and if not, he'll probably correct me.)  There could potentially be
> conflicts running the updates/proposed updates code along side the
> development code.  If nothing else, being subscribed to the proposed
> updates and the development channels would mean that any testing on the
> proposed stuff would be invalidated (as you wouldn't really be sure if the
> failure was the base+updates code, or the bleeding edge development stuff.
> So, as a good scientist, probably best to sticking with just one changing
> variable.

again, theoretically, would it make sense to draw a distinction here
between updates and proposed updates?  should it always be safe to upgrade
to development from a system consisting of, at the latest, updates, as
opposed to one which has already proposed updates applied to it?  (you can
tell i'm bored and looking for an excuse not to do any real work today.
:-)

and, coming back to seth's position earlier, he seemed to say that, if
one wants to upgrade to development, one should remove references to 
updates and proposed updates repos.  but what if one has already applied
all of those updates?  or just the official updates?  is it still safe to
move up to development?

or, putting it another way, what value would it have to remove references
to updates and/or proposed updates repos from yum.conf if you've already
applied all of those updates?  and would this represent a system that
you should even *try* to move up to development via upgrades?

rday