rebar.lock version control
Sat Mar 7 15:00:14 CET 2020
It is recommended to check the lock file in to source control.
rebar3 resolve dependencies different from tools like mix or npm. It follows a maven model of choosing the first encounter of the dependency in the tree as it is resolving. There is no "solving" for a version that matches multiple constraints in a project. So checking in the lock file is not harmful.
But note when using hex dependencies the version picked is based on the constraint on the package and not in the lock file.
Some more on how rebar3 handles dependencies can be found in Adopting Erlang https://adoptingerlang.org/docs/development/dependencies/ and the rebar3.org docs https://www.rebar3.org/docs/dependencies
On Sat, Mar 7, 2020, at 06:48, Fred Youhanaie wrote:
> In the past I've noticed that some projects have rebar.lock under
> version control, and some don't.
> Is there a general recommendation regarding this? Are there cases where
> the changes should be tracked?
More information about the erlang-questions