Re: deprecation policy

[Tim Janik <timj gtk org>]

On 5 Oct 2000, Havoc Pennington wrote:

> a) This is the embarassing category. First we commit to never have
[...]
>    this happen again; no more patches will be accepted that introduce
>    nonworking widgets. The tree and text are some of the oldest

GtkMenuFactory comes to mind immediately ;)

>    widgets I guess, and I'm pretty sure they wouldn't get by Owen and
>    Tim. So, this category of deprecation is only for legacy stuff.

> b) Little-used bloat not of general interest, e.g. GammaCurve.
> 
>    Proposal: call this level of deprecation OVERSPECIALIZED and 
>    is treated the same as BROKEN.
>     - immediately remove widgets from API docs
>     - in the first stable release after deprecation, they are 
>       removed from the headers unless GTK_ENABLE_OVERSPECIALIZED
>       is defined
>     - in the second stable release after deprecation, the code 
>       is removed entirely

i'm not comfortable with this, make this s/removed/moved/. the code is
there already and _some_ people use it. getting rid of it in gtk propper
is a good idea, but it has to stay available and maintained for people
who do use it (e.g. GtkRuler in the gimp). the best thing is probably
to open up a gtkspecials.tar.gz or similar named tarball that would
be available from ftk://gtk.org as well.

>     - bugs are fixed in the code (it is supported)
>     - new features are not accepted for the code
> 
>    Rationale: BROKEN must go away quickly because it's buggy.
>    OVERSPECIALIZED can go away quickly because few people use it.

s/can go away/should be seperated from gtk proper/

> c) Replaced by a better alternative, e.g. GtkPixmap, GtkCList.

i'm mostly fine with this. just a minor clarification, you didn't
actually mean to say "stable release" but "stable branch".
also, this whole thing should go into gtk+/docs/deprecation.txt
(along with an explanaition of GTK_DISABLE_COMPAT_H).

>  - header files will of course contain the #ifdef
>    GTK_DISABLE_REPLACED, etc. so users can see deprecation in the 
>    headers.
> 
>  - the general GTK+ trend should be toward fewer and fewer changes 
>    between stable releases, so the scary amount of deprecations from 
>    1.2 to 2.0 is not indicative of future plans.

it is not as scary as 1.0->1.2 ;)

> 
> Havoc
> 

---
ciaoTJ