3 ms·
"The developers of Go argue that the maintenance of your dependencies is your responsibility" THIS! I should also state I fall on the extreme end of the spectr
by demarq 12y ago
"The developers of Go argue that the maintenance of your dependencies is your responsibility" THIS!
I should also state I fall on the extreme end of the spectrum. My belief is that the moment you depend on upstream package X it is wholly your responsibility to track changes and adapt your code accordingly. I don't believe software versioning does anything but encourage poor security, performance and general fragmentation.
I believe that before pushing your changes to a remote repo, you locally check that everything is stable, meaning there is no dev branch or stable releases just one true master branch!
If you don't want the bleeding edge then don't 'git pull'. simple!
- dbaupp 12y agoCargo gives you exactly this, btw: if you don't want to change the version of upstream code on which you depend, don't run `cargo update`. (This applies to both git dependencies and registry dependencies.)
- demarq 12y agobelieve me I will 'cargo update' always! the problem is those who don't and still go on to publish libraries, what happens when he needs version 2.1 of X while another library needs version 3.4? And thus anyone who depends on these two libraries now ends up with duplicate libs. What if they also depend on other libs with the same problem... The world goes boom! exponential overload! ... at least it get's really frustrating after a while, twice the space, twice the compilation time. And you'll know at least one of the libs has bugs lurking in it that have been fixed elsewhere except in that lib:(