[OT] Dear Google Cloud: Your Deprecation Policy is Killing You

[H. S. Teoh]

On Tue, Aug 18, 2020 at 06:17:36PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
[...]
> I've suggested this coyly for years - coyly because it seemed so
> unclean and compromise-y: we should deprecate "psychologically", by
> keeping things but using (natural) language and UX techniques to
> deemphasize the deprecated libraries and (programming) language
> features. Use gray text, smaller, italicized, slightly more difficult
> to read. Put it one extra click away.  Start those sections with a RED
> YELLING warning. Emphasize disadvantages and point to better
> approaches. Over time, even remove documentation for deprecated
> features but leave them in. And so on. Emacs and Java have shown that
> this works.

Sounds like a good idea. Undocument deprecated features, but don't
actually remove them, leave them in so that existing code that depends
on them won't break.  But undocument them so that new code won't use
them anymore.  Either that, or wrap the docs in big yellow warning
signs.

This does not work for some things, though. Things like integer
promotion, for example, cannot be changed without causing breakage, no
matter how you try to do it.  Fundamental things of this nature will
basically have to remain the way they are forever.

But many other things could change -- even the range API, for instance,
can be rewritten -- as long as it's given a new name, like std.v2.range
or something like that. Over time, deprecate std.range, then undocument
it, but leave it in so that old code still works, but new code will stop
using it.  Of course, this also means everything that depends on the old
API will have to be duplicated and reimplemented for the new API, so
changes to foundational things of this sort will have to be carefully
weighed lest we drown in the resulting technical debt.


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying