[Gtk-sharp-list] API Freeze Policy Adjustment

Murray Cumming murrayc@murrayc.com
Thu, 01 Jul 2004 22:50:19 +0200


On Thu, 2004-07-01 at 14:36 -0400, Jonathan Pryor wrote:
> On Thu, 2004-07-01 at 11:20, Murray Cumming wrote:
> <snip what="guidelines..."/>
> > However, I break these rules sometimes myself in gtkmm, though very
> > rarely. I probably shouldn't. For instance,
> > a) In a stable branch, I have made very small changes to API to make
> > that API usable, when we have made some simple but embarassing mistake.
> 
> My interpretation of Mike Kestner's statements follows this line of
> reasoning.  He even provides the perfect example:

His blog entry suggests a lot more than that, and that's why I'm
mentioning it:
"
We are also going take advantage of the nice Assembly versioning and GAC
functionality of mono to allow the addition of missing API related to
the 2.2 Platform and convenience overloads for methods. This gives us a
fair amount of flexibility to continue to improve the 2.2 bindings for a
while, without breaking existing code developed against Gtk# 1.0."

> > > However, if a parameter is really an int[], but the generator has
> > > produced an "out int" parameter (as is the default case for an int*
> > > parameter that has not been marked as an array with metadata), there is
> > > no way to use such a method with the out int semantic.  Anybody that
> > > would try to use it as such would quickly find out that it doesn't work,
> > > and would probably be filing a bug report.
> 
> If the choice is between waiting (at most) 6 months for an API fix (for
> the next stable release) or waiting a few days to a few weeks for a
> point-release, I'll take the point release.  I suspect most developers
> would agree.

The API rules and the whole release process are not meant to make life
difficult for you, or to get in your way. But large API changes have no
place in a stable release. The GNOME developers seem quite united in
their approval of this policy.

-- 
Murray Cumming
murrayc@murrayc.com
www.murrayc.com
www.openismus.com