Re: deprecation policy
- From: Tim Janik <timj gtk org>
- To: Havoc Pennington <hp redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: deprecation policy
- Date: Sat, 7 Oct 2000 02:49:27 +0200 (CEST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]