In PR #10392 @alainfrisch notes:

As per the discussion on that issue, Stdlib.{min,max} are not marked as deprecated. I think it will make it harder to eliminate them, and switching to specialized functions is easy enough (and otherwise, turning turning off the deprecated warning, or redefining local versions of min/max if used on complex types), so my preference would be to mark them as deprecated right now. But oh, well.

I don't think turning off warnings explicitly is a good strategy, it defeats the purpose of having a deprecation procedure. But then we also don't want programmers have to live with warnings that they can't act on other than by silencing them.

@xavierleroy once asked me a write up for a deprecation procedure. I never heard anything back. But the idea there was to wait for the deprecation workaround to hit debian stable before starting the effective deprecation so that people mostly don't have to live with the warning.

However that introduces quite a bit of maintenance bureaucracy (delay between introduction of the workaround and the formal deprecation) and it may feel weird to align the project on whatever debian decides for its maintenance cycles. But that assumed the current state of affairs.

This could be simplified by if we had:

1. A version parameter on @deprecated deprecated-version, that indicates the version deprecated-version in which the feature is deprecated and the workaround introduced.
2. A cli flag -min min-version that indicates the minimal OCaml version min-version with which the source we are compiling is supposed to compile (defaults to the compiler version itself).

That way you only start warning when min-version >= deprecated-version