Re: platform compatibility policy

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs eazel com> writes:
> Havoc, would you like to take ownership of leading discussion, writing
> up new drafts that capture the discussion

OK
 
> >  - bugfix micro releases do not get remotely as much QA 
> >    or peer review as minor releases
> >  - we have had bad experiences in the past; e.g. GnomeDruid 
> >    was added and was totally broken
> >  - it's hard to document and keep track of which version has
> >    what if you add interfaces in micro versions
> >  - it makes CVS branches much more annoying to maintain
> > 
> > "Strong justification" means the changes should be essential hooks for
> > some important feature. i.e. just an aesthetic change like adding an
> > accessor function or fixing a function name would not be good
> > enough. "Large interface" means a whole new facility, such as a new
> > widget.
> 
> The problem with this section is that it requires a lot of judgement,
> unlike the stated standards for when you may break backwards
> compatibility. People are going to argue over what is strong
> justification and what is a new feature, I think, and my goal for
> having a policy is to be able to resolve disagreements just by
> pointing to the policy.
> 

The only totally objective rule I can think of is "no new interfaces
in micro releases." But this seems to make people unhappy. 

Examples of possibly justifiable new interfaces in micro releases I
can think of:

 - the mini icon stuff in libgnomeui
 - the hooks Owen added to GTK stable recently to support
   more interesting themes (these new functions have _experimental 
   in the name)
 - the GnomeCanvas dither stuff

I think it's clear that big new features should not go in micro
releases. It's just a Bad Idea if we want a reputation for good QA and
stable, well-thought-out software. So the question is about these
"small hooks."

Can anyone think of an objective way to define "small hook" vs. "big
new feature"?

Even "lots of small hooks" or "lots of small enhancements" are IMHO
bad, because if you start doing this all over the place it becomes
destabilizing just as big new features do...

For the above examples (mini icons, theme hooks, canvas dithering)
they all could have waited for a minor release (1.2 or 1.4), since
they are used in features that were part of a minor release. They just
end up in a micro release because we have a "stable branch" not a "1.2
branch" and "1.4 branch." So possibly the no-changes-in-micro rule
works OK.

Just noticed that GTK's versioning doesn't work the way we're
describing here, e.g. GTK 1.2.9 is in GNOME 1.4. So by
major/minor/micro we're referring to GNOME version not library
version.

Havoc


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers