Re: Upcoming platform deprecations

[Elijah Newren <newren gmail com>]

On 10/10/05, Murray Cumming <murrayc murrayc com> wrote:

> > Agreed; having to learn on IRC by word of mouth to "not use X; it's
> > broken"
>
> These things continue to work about as well as they ever did.

Yes--they continue to possibly do just as much harm as good, IMO. 
Lots of people don't get the message and thus continue using
suboptimal stuff anyway, and when someone does learns that X is "bad",
they wonder if other modules are also bad unless they can find some
official place that mentions what is actually intended.

> > or to "not use X because it will be replaced by something sane
> > in the future" is not cool.  It's part of what Brian's been
> > complaining about.  Obviously, we need to pick our wording carefully,
> > but we need to communicate intentions somehow.
>
> The only reason to not use something because it'll be replaced
> real-soon-now is "because I want to use the cool new stuff that all the
> cool kids are using". But API/ABI stability is about what's safe and
> stable and boring, not about what's cool. ISVs don't want to keep
> re-porting to this year's cool API - they just want to use an ABI that
> will keep working. And they get frightened at the slightest suggestion
> that it won't keep working.

Yes, that's true.  But this thread really isn't about making stuff
stop working (I hope!), just about deprecation (gnome 1.x stuff still
works and gnucash still uses it).  Also, we've never really told ISVs
what we think they should use.  There's been quite a few times that we
(meaning "various Gnome hackers") have told people that certain
modules in the platform weren't cool and should probably be avoided by
ISVs and others, and we even had libgnomeprint dropped from the
platform from 2.0.x->2.2.x (and then accidentally get released as part
of the platform on the ftp site through 2.11 or so).

It'd be nice if we didn't have to deprecate stuff.  It'd be nice if
everything had super solid support like gtk+.  But, given that it
doesn't, isn't it best to communicate intentions and our feel of the
state of the modules (though of course, making sure that we don't
break stuff and do maintain the API/ABI stability promise)?  Isn't
that what Brian has been harping about all along?

- Elijah