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

I think this is a reasonably restriction for APIs that are exported (with installed headers), unless steps are taken to suppress export. It doesn't make sense for truly "internal" APIs of course :-)

- Bill

Elijah Newren wrote:

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
       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?)...


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