I want to share some concerns about storing mix.lock file in VCS for libraries. The current version of Library Guidelines page has zero mentions of mix.lock and the established community practice is to indeed version control mix.lock.

Which is meaningless and might be even harmful in some scenarios.

Consider the library A that depends on another library B. B occasionally introduces a breaking change in the minor updates. Even if A library has nightly builds turned on, it continues to be green because in mix.lock there is a previous version of B. All the projects, depending on A get broken, because they ignore A’s mix.lock.

Without mix.lock in the VCS, A library author would have been informed a night after B upgrade. With mix.lock file in VCS, they will be informed by a tornado of issues from A users days after.

A less exotic case might be also taken into account: A depends on B and C, then B and C start conflicting on D at some point, but A nightly builds are still all green, because there is mix.lock in VCS and A is never tried to compile against modern versions of B, C, and D.

This is all not expected in our great self-organized ecosystem, but things happen. Currently, I personally switch nightly build on and remove mix.lock from VCS. It makes me think I will, at least, be notified about issues with the latest dependencies consistency the very next night.

I think removing mix.lock from VCS for libraries is a good practice in any case and I think we might enforce/suggest it via Guidelines I linked above.

Thoughts? /cc @josevalim