search

dnsimple / erldns

DNS server, in Erlang.
MIT License
398 stars 98 forks source link

Add revision numbers to rebar dependencies #70

Closed wgslr closed 6 years ago

wgslr commented 7 years ago

Specifing dependencies withour revision number or tag is unsafe, as a change in them can suddenly brak this app and any other app using erl-dns as its dependency. This pull request fills rebar.config with current revision for each dependency.

aeden commented 6 years ago

I've locked to master for everything for now. If we run into breaking changes then I can start freezing problematic libraries to specific tags.

wgslr commented 4 years ago

Hi @aeden The "run into breaking changes" scenario has just occured. In our application we use erldns specified as

    {erldns, {git, "https://github.com/aetrion/erl-dns.git", {ref, "24998cd"}}},

Because of erldns' rebar.config lacking revision freezes, its dependency - dnsimple/dns_erlang - updated itself to the newest version, incompatible with the erldns version we use (for example because of the app name change). This suddenly broke builds of our application, which could have been easily avoided had erldns tracked the dependency revisions.

aeden commented 4 years ago

@wgslr sorry for breaking your builds.

erldns is now handling all dependencies through hex. What needs to be done, if anything, for your builds to function properly again with the latest rebar configuration?

wgslr commented 4 years ago

Thank you for your response. At the moment we (onedata/oz-worker) resolved to hold onto the currently used version by making a fork and freezing the dependencies to older versions, so I don't know whether the hex build causes any issues. Surely will let you know after we try to upgrade. Mostly I just wanted to show an example why dependency version tracking (as in the original PR) is useful.