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 <[EMAIL PROTECTED]> 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
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
