On Thu, Sep 21, 2017 at 8:57 AM, Niklas Hambüchen
Deprecation-marking does not break any code, it is the softest way to make a transition. The Java community has this figured out: Deprecations are common, they don't break the build, they don't change behaviour, downstream libraries adapt quickly to them, and the whole ecosystem can advance to a more solid foundation gracefully.
As I remember it, where I worked there was a distinction between deprecations and warnings. Deprecations had no visible output outside the documentation, unless you used an IDE and turned on the dotted-underline feature, while warnings would be printed during the compile. You were not supposed to deprecate anything without a clearly documented "do this instead" but you didn't need a plan to fix all the callers. But to emit a warning, a bounded-time plan was required, which probably involved a global fix via automatic refactoring. Otherwise, warnings accumulate, and once they get past a certain amount everyone ignores all of them equally, which is a loss as we lose the high value ones too. Most of them come out of compiling stuff you don't own and don't understand and don't have time to go fix. If I were to suddenly get 10,000 lines of warnings... well, if it can be fixed with a global search and replace then it's ok if they only indicate a few real problems. But if the fix is more complicated and requires individually looking at each place, then they had better have a pretty good positive rate. Otherwise I wind up turning off the warning and it might as well not exist. You could say there's a place for low value lint type warnings which you could turn on just for hlint style suggestions, but it needs to be integrated with the source control so it can warn only about the bits that you just changed. Otherwise no one can repeatedly comb through the 10,000 suggestions in case some have been added, so in practice it just stays off forever. Also in my experience the bit about "downstream libraries adapt quickly to them" is wildly optimistic :)