Re: Deprecations

[Magnus Bergman <magnus bergman observer net>]

On Thu, 27 Apr 2006 10:30:12 -0400
Owen Taylor <otaylor redhat com> wrote:

> On Wed, 2006-04-26 at 09:22 +0100, Ross Burton wrote:
> > Hi,
> > 
> > Would it make sense to mark all of the deprecated API in GLib and
> > GTK+ with G_GNUC_DEPRECATED, so that people who are not using the
> > DISABLE_DEPRECATED macros still get warned that they are using
> > deprecated functions?  At the moment it's very black and white, and
> > I think deprecation functions need a grey...
> 
> I think muddling the deprecation system like this is a mistake.
> 
> Say, I'm a developer working on an app that is supposed to work with
> GTK+-2.6 and newer, so I develop and compile with GTK+-2.6.
> 
> I have a user who takes one of my releases, and compiles it with
> GTK+-2.10 ... they get 20 zillion warnings, and will have little
> chance of seeing if something *actually* went wrong with the
> compilation.
> 
> They can't even send me a patch to fix these warnings, because
> the facilities that caused the functions to be deprecated may
> not exist in GTK+-2.6.
> 
> G_GNUC_DEPRECATED is certainly better than what we do know in one
> way ... it produces warnings *without* producing miscompilations;
> but I don't think there is any real way to take advantage of it
> within our current deprecation system without a ton of extra
> typing and complexity.

Wouldn't it be possible to let the user choose which APIs should be
marked with G_GNUC_DEPRECATED when compiling their applications? If the
application requires GTK+-2.6, only APIs deprecated in that release
would be marked deprecated. Let the user define something like
GTK_OLDEST_SUPPORTED_VERSION (which would default to 2.0) and have
macros like GTK_DEPRECATED_IN_VERSION(version) for the APIs (perhaps
it could warn about APIs newer than the oldest version supposed to be
supported as well). I don't know if this would be too complicated, just
an idea.