<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 1:18 AM, Tristan Sloughter <span dir="ltr"><<a href="mailto:t@crashfast.com" target="_blank">t@crashfast.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm just throwing my thoughts out there. This isn't to cover all<br>
features I'd want to see in a package manager, but instead just the ones<br>
I know are "controversial". These are also the direction we've gone with<br>
rebar3 (<a href="http://rebar3.org" target="_blank">http://rebar3.org</a>).<br>
<br>
* Binary packages<br>
<br>
Why build from source if you don't need to? Most Erlang applications<br>
have no native code.<br>
<br>
* No semver enforcement<br>
<br>
I mean, why bother? For one, you can't actually force semantic<br>
versioning. You can require the version be of the format<br>
MAJOR.MINOR.PATCH+[metadata] but not the semantic part.<br>
<br>
I think forcing the format in the name of "semver" is confusing and<br>
wrong.<br>
<br>
* Strict version declarations<br>
<br>
No ">=1.0" or "<1.0 and >0.5". The project should set a version number<br>
of the dependency it relies on.<br>
<br>
"Solving" dependencies is a matter of choosing the highest version of a<br>
dep in the dependency tree. This is also followed by maven,<br>
<a href="http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html" target="_blank">http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html</a></blockquote><div><br></div><div><br></div><div>What if you want to support a package from version 3 to 5 but not 6 neither 1 or 2 due  breaking changes in the API?</div></div></div></div>