Skip to content

Deprecation warnings shouldn't be fatal by default #1843

@NathanReb

Description

@NathanReb

I recently deprecated a type in yojson and although I should've done things a bit differently it came with a lot of unwanted breakage, see ocaml-community/yojson#79 and ocaml-ppx/ppx_deriving_yojson#91.

Not all of these issues are directly related to dune but it made me think about how dune handle those warnings by default and it seems odd.

Making deprecation warnings fatal breaks the whole logic behind deprecation cycles. We deprecate values and types in a library to help users gently migrate their code before breaking compatibility in a later major release. If the warning is fatal, it makes deprecation a breaking change on its own.

As a maintainer I don't feel like asking users to change their build profiles everywhere and thus I end up running around fixing stuff like I just broke compatibility in a minor release which I didn't.

As I already mentioned it in ocaml-community/yojson#79, I'm not sure what the best way to handle those is. Completely silencing it is too much but we probably don't want too much noise on the build output either.

I'm really curious about what the dune team thinks about this so please let me know!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions