Re: Accompany index of deprecated symbols with GTK+ version?

["Jan-Oliver Wagner" <jan-oliver wagner intevation de>]

On Monday 13 November 2006 22:36, David NeÄas (Yeti) wrote:
> Mass removal of deprecated symbols *only* for the purpose of
> removal of deprecated symbols is a good method to waste time
> and bring new bugs.

my understanding of "deprecated" is that those methods are not
maintained anymore. Or at least not maintained as good as
the main API is maintained.

Also my understanding is that whenever GTK+ 3 should happen,
all deprecated symbols will not be there anymore.

I might be wrong with these assumptions!
Any URL where I can learn more about the GTK+ deprecation philosophy?

However, I learned that for quite a number of methods it is
a good idea to drop the deprecated ones and instead
use the replacements (less buggy, better UI, better source code
readability, less source code, better performance).
Usually it should indeed make sense, because otherwise there
would have been no need to implement a replacement ;-)

> Now, if you think such an index would be so useful you can
> write a gtk-doc patch to enable some kind of version info in
> the conditional compilation constructs (the easy part) and
> actually add the proper deprecation version info to the
> headers (the hard part).  Or invent some other method to get
> the information there, like semiautomatic extraction using
> tarballs of previous Gtk+ versions...  But in my opinion it
> does not worth the work.

Seems noone else is interested in these things I need/care.
So indeed it does not make sense to implement a general solution.

Best

        Jan

-- 
Jan-Oliver Wagner: www.intevation.de/~jan  | GISpatcher: www.gispatcher.de
Kolab Konsortium : www.kolab-konsortium.de | Thuban    : thuban.intevation.org
Intevation GmbH  : www.intevation.de       | Kolab     : www.kolab.org
FreeGIS          : www.freegis.org         | GAV       : www.grass-verein.de