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:05:39 +0000, Mark McLoughlin <markmc redhat com> wrote:
> On Tue, 2005-02-22 at 16:50 +0000, Bill Haneman wrote:
> > We still have the problem that we are 6 days from code freeze with a
> > change in API which we depend on.  So the solution proposed below
> > (re-implementing the libwnck calls) is not a runner for us.
> 
>         Elijah's suggestion to implement your own versions of the libwnck calls
> is just a suggestion for you to protect yourself against future libwnck
> API changes.
> 
>         If you can't do that before the code freeze, I'm sure you can easily
> adapt to the new APIs in that time. My understanding is that passing
> gtk_get_current_event_time() for the timestamp argument will do exactly
> what the API did before, but not what you want it to do under certain
> circumstances.

Correct.

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

Cheers,
Elijah