Re: Upcoming platform deprecations



>> > However, I'm personally against making non-official official
>> statements
>> > that just spread doubt. An API is either deprecated or it's not.
>
> If so, that would mean your suggested wording for that page is flawed
> too, Murray.  (Which I happen to disagree with).

Yes, I'd prefer not to have my wording either. I just thought it was a
better way of saying "soon to be deprecated", without suggesting "soon to
be broken". I'd prefer not to have either.

> 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.

> 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.

Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]