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

[Elijah Newren <newren gmail com>]

On Tue, 22 Feb 2005 17:40:10 +0000, Mark McLoughlin <markmc redhat com> wrote:
> On Tue, 2005-02-22 at 10:19 -0700, Elijah Newren wrote:
> 
> > >         i.e. the change has happened, you're going to have to deal with it. I
> > > don't think this was neccessarily went against any policy, because we
> > > don't have any policy on this other than "libwnck can change its API at
> > > any time". I do think, though, that we should have a better policy than
> > > that - e.g. that unstable APIs should remain frozen from API freeze time
> > > until the next development cycle.
> >
> > Sounds reasonable to me for future releases.  Do we want this to just
> > apply to libwnck, or to all unstable APIs in the desktop release?  If
> > so, we need feedback from others whether this is reasonable and
> > whether we want to add this as a rule for being in the gnome-desktop
> > release.
> 
>         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?)...

Elijah