# Serious OPAM package quality issues **URL:** \ **Category:** Community\ **Tags:** user-feedback, opam\ **Created:** [June 30, 2017, 8:26pm UTC](https://discuss.ocaml.org/t/serious-opam-package-quality-issues/484 "2017-06-30T20:26:49Z")\ **Posts on this page:** 1\ **Showing post:** 54
**Author:** ![ivg](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/ivg/32/103_2.png) [@ivg](https://discuss.ocaml.org/u/ivg)\ **Post date:** [September 18, 2017, 4:28pm UTC](https://discuss.ocaml.org/t/serious-opam-package-quality-issues/484/54 "2017-09-18T16:28:19Z")
> Do you mean because of open usage and the possibility of name overlap? Not only this. For example, if you add a new field to a module signature and it is used somewhere as a functor argument, then it is strictly an API breaking change. Given that we have `module type of` construct, any module can be potentially used for its signature somewhere. Formally, if a new interface is a subtype of an old one, then we do not need to bump the major version. The problem is with arrows as always, i.e., with functors. Since module types may occur on both sides (being either an argument, or a resulting type) we may have the variancy problem. Basically, we can add more fields to an interfaces that is produced, but we may only remove fields from an interface that is consumed. (And can’t touch interfaces that are both consumed and produced). --- _[View the full topic](https://discuss.ocaml.org/t/serious-opam-package-quality-issues/484)._