OpenOffice 3.1

Adam Williamson awilliam at redhat.com
Mon May 11 22:21:37 UTC 2009


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




More information about the fedora-devel-list mailing list