Improvements to deprecations related to
There is a JEP for improved deprecation in Java 9. I see it's linked on jira. They recently simplified, in order not to encode reasons and lifecycle disposition and replacement API that should be discussed in documentation. I can't tell if they eliminated "condemned" or renamed it "forRemoval"? But one point is that it doesn't give enough information, since projects have arbitrary lifecycles or policies for whether to remove deprecated API.
In a word, I'm not sure
Also, javac says "has been deprecated." For some reason it sounds more natural than "is deprecated." That may be because the verb is transitive or for sense of completion. "--What happened to the food? --The food has been eaten." Food in general is eaten because edible.
The whole reason why
I know the Java 9 JEP. The problem is that they are still living in a world where the only imaginable way of dealing with deprecations is their own. From an improvement point of view, I think that
"deprecated (since FooBarLib 33.2)" is meaningful, because developers can check what the project's deprecation policy is.
That's the idea behind it: Instead of giving people "13 deprecation warnings, and now deal with it" we provide them with some additional helpful information which helps them to determine how critical a deprecation is:
A Scala developer already knows the Scala deprecation policy, therefore he/she has to check only FooBarLib's and BazProject's policies, instead of checking every single deprecation manually.
"has been" -> "is" was just to offset the potential width increase from the since information.
I like the uniformity for flavors of deprecannotations, and I liked the idea of emitting the since.
But when I saw the test output, as you say, it makes the lines longer. Maybe that's OK, I don't know; it probably just looks more repetitive in the test output. If you get just a few such messages, then you want all the info, and not "re-run with -Ydeprecation-explain".
@adriaanm currently we print the summary ("there were n dep warns") only when
do you propose to print the summary also under
we could also not directly emit the warnings, but store them also under
Method `deprecationWarning` got a new parameter in scala/scala#5076.
Sorting may have been my suggestion. @Ichoran knows the optimal way to sort.
Stopped by to say how neat the build looks.
Maybe someone will add an ASCII graph with versions on the x-axis.
Or like the JIRA graph, comparing the pace of new deprecations to the rate at which we still incur them.