Deprecation process documented?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, February 24, 2015 10:05:21 H. S. Teoh via Digitalmars-d-learn wrote:
> On Tue, Feb 24, 2015 at 09:55:28AM -0800, Jonathan M Davis via Digitalmars-d-learn wrote:
> [...]
> > Regardless, when a symbol is either marked as "scheduled for
> > deprecation" in the docs or outright deprecated, a date is usually put
> > in the docs for when it will be moved to the next deprecation stage,
> > though in the case of "scheduled for deprecation," there's a decent
> > chance that it'll be marked with the next release number rather than a
> > date, since the idea there is to give folks a release of leeway so
> > that they can avoid deprecation messages when building with master
> > rather than give them a particular period of time to change their code
> > before the symbol goes away, as is the case with symbols that are
> > actually deprecated.
> [...]
>
> What about Walter's recent complaint that certain old symbols have gone
> away and no upgrade path was presented to the user, just an inscrutible
> error message? I thought the consensus from that discussion was to leave
> deprecated symbols undocumented but still defined (even if it's just a
> no-op stub with a deprecation message or static assert pointing the user
> to the new symbol(s)).

There was some discussion of that, though I don't know that a consensus was
reached. I don't remember all of the details of that discussion though.
However, I do tend to be very much in favor of _not_ leaving cruft around
like that long term, so that may color what I'm remembering. However, the
problem that Walter ran into was because he waited over two years before
updating his code, and trying an intermediate release of the compiler and
std lib would have taken care of the problem.

- Jonathan M Davis