DIP 1013: The Deprecation Process -- Community Review Round 1

[Mike Franklin]

On Wednesday, 18 April 2018 at 12:28:59 UTC, Jonathan M Davis 
wrote:
>> > In order to facilitate on schedule deprecations, a comment 
>> > of the format @@@DEPRECATED_[version]@@@ should be added to 
>> > the top of the code to be removed/disabled.
>>
>> Is `[version]` the version in which the deprecation took 
>> place, or the future version in which the next stage is to 
>> take place. For example, if I'm deprecating a feature in 
>> 2.080, should `[version]` be 2.080, or 2.085 (the version in 
>> which the features is changed to an error)?
>
> As I said before, it's never changed to an error. The DIP quite 
> specifically never does that, and really I don't think that it 
> should.

The current process, as I understand it for language features, is 
the deprecated feature is a deprecation message for a year, and 
then an error for a year.  After 2 years of being deprecated it 
is removed.  Perhaps you were only referring to a deprecated 
library feature.

Mike