terminology and the hierarchy of releases

[Axel Thimm]

On Tue, Feb 10, 2004 at 09:44:31AM +0000, Telsa Gwynne wrote:
> On Mon, Feb 09, 2004 at 01:16:08PM -0500 or thereabouts, Robert P. J. Day wrote:
> > On Mon, 9 Feb 2004, Will Backman wrote:
> > 
> > > before.  Wait until next text release, repeat.  This would prevent
> > > upgrades from FC1 -> FC2rc1 -> FC2rc2 ->FC2rc3.
> >  
> > it's already understood that you can't upgrade *from* a test release
> > to any later release.
> 
> And people still do it every single time. Even on a list where
> everyone knows the result is unsupported. I think such a list is
> the exception rather than the rule, too.

But wouldn't it be nice and attract more testers if the upgrade paths
were that way? And I don't think it is difficult to achieve.

o If a package has to be downgraded bump up its epoch (almost the only
  legitimate use for an epoch IMHO). E.g. the ntpd package that was
  downgraded should have bumbed up the epoch.

o If a package has to be renamed (very seldom in redhat trees), the
  old one gets obsoleted (never seen redhat to not do that, but I am
  mentioning this to be complete).

o If a package has to be removed w/o any replacement, let it be
  obsoleted by fedora-release, or a special clean-up package
  fedora-remove-obsoleted-developement. It can be argued that this is
  not even neccessary to keep upgrade paths, so consider this optional.

I think it is worth while to have people surf on rawhide/developement,
or upgrade from test1 to test2 to ... to final release. The above
boils down to epoch increase on package downgrades.

Note, this is about packaging, not about the contents itself,
i.e. make sure that upgrade paths work across
development/testing/releases, but no guarantees about the rpms
themselves (otherwise it wouldn't be fun to surf on rawhide w/o any
risks, would it? :).
-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20040210/6b342df3/attachment.bin