Re: Enforce some restrictions on unstable APIs in the desktop release? (Was: gok broken with new libwnck)

On Tue, 2005-02-22 at 10:53 -0700, Elijah Newren wrote:
> On Tue, 22 Feb 2005 17:40:10 +0000, Mark McLoughlin <markmc redhat com> wrote:
> >         Yeah, it'd be for all libraries in the desktop, but not in the platform
> > - e.g. libgnome-menu would be another one.
> Okay, we need to get feedback from developers of other modules, such
> as eel, gal, libpanel-applet (actually, I guess we already have Mark's
> feedback...), libgnome-keyring, gstreamer, libgail-gnome,
> libgnomeprint, libgnomeprintui, libgtkhtml, libgtop, librsvg, libsoup,
> libmetacity-private (seems like a strange rule for a library with this
> name, but technically it falls under "all libraries in the desktop"),
> libstartup-notification, vte (except that I'd be ecstatic if it
> changed), and any others I missed (do the various libnautilus*
> directories under nautilus count?)...

I often change eel after the freeze in order to fix bugs in nautilus.
But I see the point in this, and its not a bad idea. How about limiting
it a bit though, so that after API freeze such libraries aren't allowed
to do api-incompatible changes.

This means you can still add functions, and in the libwnck case we have
here you could have added the new function, and then made the old one
call the new one. (This would require a new name for the function of
course, but at least you could fix the bug.)

 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an unconventional day-dreaming vagrant who dotes on his loving old ma. 
She's a sarcastic kleptomaniac schoolgirl with an MBA from Harvard. They fight 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]