terminology and the hierarchy of releases

[Jay Turner]

On Tue, Feb 10, 2004 at 06:23:29PM +0100, Axel Thimm wrote:
> That's exactly the issue scaring rawhide surfers and point to point
> testers away IMHO (at least me ;).
> 
> I surely know epochs are evil and long term they should be replaced by
> a upgrade-path local solution as suggested in other threads and on
> rpm-list.
> 
> But package downgrades are the only real legitmate use for epochs
> (other than upstream version hickups). If a bug is such severe that it
> requires a package downgrade it is severe enough to have its epoch
> bumped up (of course it's better to have the package fixed).
> 
> It isn't hard work to keep upgrade paths consistent throughout
> "developement" and have "testN" and releases be treated like time
> snapshots of it. How many packages were affected by package downgrades
> in the last couple of months? Less than a dozen compared to thousands?

Here's a good example of why this is a total PITA.  This is a snippet from
a post to fedora-devel-list from Jeremy Katz:

>>   b) evolution
>>       unable to (configure to?) use maildirs
>Upstream.  Although this will become a non-issue for FC2 very soon.
>With the new schedule for evolution 2.0, I'm going to be reverting the
>package in development back to a 1.4.x later in the week.

So, here we have a package which is going backwards in development, so that
leaves us with two options.  Either we spend significient resources making
sure that everything can go forwards and backwards just fine, because
people might want to upgrade from one test release to another, or we just
accept the fact that it's not something which will happen from one general
release to another and use those resources to do something more productive.
We've had cases where the entire KDE chain has "regressed" from one beta to
another.  And tacking on an epoch to the older packages, just so they
appear "newer" doesn't make any sense, as it's a problem which only
developers are going to see.  But, if we did attach an epoch, we would have
to continue to carry it forward from that time on (into the public
release.)

There are very few times that an epoch is the correct answer to a problem.
One being when perl just backwards in their release numbering.  The epoch
allowed us to say to RPM that even though this new package appears "older,"
it really isn't.

- jkt


-- 
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*
Jay Turner, QA Technical Lead      jkt at redhat.com             Red Hat, Inc. 

        Reality is merely an illusion, albeit a very persistent one.
                                                   - Albert Einstein