News for hackers. Stuff that matters.
Re:A Proposal for Package Versioning in Go by clhodapp on Monday March 26, 2018 @08:33PM (#16684092)
That may be what things are converging on but in my opinion, any system that imposes a "single dependency version per compilation unit" policy is not a "real" dependency management solution. That approach creates a tremendous amount of friction because it pretty much ensures dependency hell if there are transitive dependencies with separate release cycles (and there very much should be able to be).

Edit: I just realized that we may have a different definition of "compilation unit". If you mean "single program" then my point stands. However, if you just meant some sectioned-off part of the program, then I think the drawbacks of that are far less. Basically, I think that it is useful to be able to have access to multiple versions of a datatype (e.g. if you want to write a converter from old -> new) but that use case is far more fringe.

Re:A Proposal for Package Versioning in Go by XorNot on Tuesday March 27, 2018 @08:41AM (#16687695)
As a sysadmin I object to the notion that old to new conversions are a "fringe" use-case. Pretty much all my coding (I'm a "devops" sysadmin-type) is exclusively "I need to wrangle all versions of thing 1 into a type of thing 2 or between several versions of thing 1".

If backwards compatibility is important, then letting me use multiple versions side-by-side in the same modules easily is damn important.

Re:A Proposal for Package Versioning in Go by steveklabnik on Tuesday March 27, 2018 @03:17AM (#16686068)
To be clear, Cargo fits the latter definition; you can't depend directly on two different versions of a package, but you can transitively.