First win:

scalacOptions in Compile += "-deprecation-policy:-scala.collection.Iterable.stringPrefix",

Speaking string prefixes, maybe taking just a prefix of the name is good enough, rather than requiring a package.

and a version string can include a library name: "-deprecation-policy:since<Acme Platform 1.5", where the library name must also match the deprecation since attribute.

Does that also work if the library name contains a dot? Random example: -deprecation-policy:since<Scala.js 0.6.23 😉

Hypothetical syntax in'from for the deprecated member accessed from a location. Then 'from means any deprecation emitted from that location. But still maybe find better punctuation. (Edit: parens? com.acme.stale(com.acme.app) or com.acme.stale(app/App.scala:17:8) or "early init"(app/App.scala:17:8) where quotes mean match text not element.)

I found "in" and "from" terminology confusing. There's the deprecated thing, which might be a program element but might be a feature like early definitions; and there is the location, nominally the error position, which could be expressed as a source position or a program element.

The other feature to inflict is a filtering reporter that uses output from a previous run, similar to a partest check file, as a whitelist of messages. For a huge list of warnings, it's easy to update and then ignore the huge list; you'd only see new warnings. Conversely, it's easy to edit the list for warnings you actually want to fix. That would also be an opportunity to match messages like "early initializers are dep" at any position to either ignore them or escalate them.

Perhaps we should give people the option to apply a regexp filter to the warning messages.

I think that we need something sophisticated here, as discussed with @retronym so suit our specific environment

In general we need to ability to deprecate some things that are not yet deprecated, and mark some things that are deprecated as not. This sounds a it weird, but here is the logic

When we decide to migrate to say 2.13, we will need to move code to a common subset, something that we can compile in 2.12 and 2.13, for an extended period of time.

Generally we have zero deprecation policy. When migrating the code we will need to change to not use for example scala.collection.breakOut, so we can migrate the code to a different pattern - e.g. .toIterator.map(…).toSet, and we need to ensure that usages of breakOut don't creep back, so we could deprecate breakout for our 2.12 compiles

Similarly we make look at an API that is deprecated in 2.13, but decide to cope with that rewrite after we have migrated to 2.13. Clearly we don't want to compile 2.13 without deprecation, as we need a finer control

Also in some applications we want to restrict usage of some APIs, e.g. scala.collection.parallel._ or use of views when these cause issues with other infra in the application or some local code standard

All of these need finer control to switch on or off deprecation at a fine grained level

@mkeskells suppressing a deprecation is already supported; I'll try to add ad-hoc deprecation.

The general use case of: Apply 2.13 deprecations to my 2.12 build, I'll consider out of scope here.

I'll clean up the "policy" syntax and add syntax for "label".

Parking this reference here, since opinions are floated about deprecation policies. From guava:

APIs without @beta will remain binary-compatible for the indefinite future. (Previously, we sometimes removed such APIs after a deprecation period. The last release to remove non-@beta APIs was Guava 21.0.) Even @deprecated APIs will remain (again, unless they are @beta). We have no plans to start removing things again, but officially, we're leaving our options open in case of surprises (like, say, a serious security problem).

@som-snytt what is this mechanism? The need that we have is ad-hoc, not related to particular versions. I know that other organisations have also had this need and crafted their own solutions
We need to escalate and de-escalate particular deprecations

I needed this today. While trying -Xlint:deprecation, I remembered something about coping with stringPrefix.

This may be a blocker for enabling -Xlint in the build, but the only legit use case is when API is made private, so it is still used internally. A workaround there is to create new internal API.