On Mon, 2009-05-11 at 15:21 -0700, Adam Williamson wrote: > On Mon, 2009-05-11 at 15:05 -0700, Jesse Keating wrote: > > On Mon, 2009-05-11 at 23:57 +0200, Kevin Kofler wrote: > > > 4. the major feature release or rewrite, e.g. KDE 3 -> 4, Amarok 1 -> 2 > > > etc. – those come with known feature and stability/reliability regressions > > > make absolutely no sense to push as a stable update to a released distro! > > > (Of course there are some project releasing "new major versions" which are > > > not of that type, but in that case they should be handled like "minor > > > feature releases" above. But e.g. Amarok 2 is most definitely a major > > > feature release with significant code rewriting.) > > > > The problem I think we're having is that while KDE may use sane numbers > > to represent these 4 classes, not all upstreams do. But users see KDE > > do a a.b.n to a.b.n+1 or even a.b to a.b+1 and think that it's OK to do > > that with their software too, even though their upstream may do massive > > feature changes between a.b and a.b+1. > > > > Basically trying to insert numbers anywhere in this discussion is going > > to fail, and we have to stick to concepts like you outlined. For what > > its worth, I agree with the 4 classes and which are appropriate or not. > > Unfortunately I don't think everybody agrees. > > Exactly. I'm replying to Jesse to keep things compact, but to address > one point from your post: "equating "version upgrades == unstable" is > not the point. It's not ==, it's *may possibly equal*. > > As I said, one of the two practical update policies is "minimum possible > change necessary to fix the specific issue being addressed". If, say, > you want to fix a single bug in awesomeapplication 1.0, and > awesomeapplication 1.0.1 does nothing but fix that bug, then shipping > awesomeapplication 1.0.1 as an update passes the policy. It's not as > simple as saying "you can't ship any version updates". The policy is, > quite simply, as it says: you ship the minimum necessary code changes to > address the specific bug the update is intended to address. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > Which would have left us with KDE 4 in F9 instead of KDE 4.2.2 and RHEL 5.3 would have been left with Firefox 1.5 instead of Firefox 3.0. One cannot ignore the fact the maintainer can, and should have the final decision as for what counts as a stable release and/or which features are important enough to justify the risk of a possible breakage. - Gilboa -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
