3 ms·
Right, but you could do that with version numbers, too. The difference between updating from "whatever version was pulled in at the time we first set up the rep
by lostcolony 11y ago
Right, but you could do that with version numbers, too. The difference between updating from "whatever version was pulled in at the time we first set up the repo with this library" and "current" is no different than updating from "version X" to "version Y", except that you don't know what the differences are, and there's no way to determine that it would be easier (and possible) to update to version X.1, since that includes the fix/feature that triggered the desire for an update, and doesn't break as many things, so requires less work.
- skybrian 11y agoYes, if you're going to check stuff in locally, you need to document which version you pulled to make the next upgrade easier. So it's not like nobody is keeping track of versions (or better yet, git commits). But this can all be done using a separate system. The build system itself doesn't need to know anything about versions. If you look at Bazel, it doesn't let you specify versions for target deps. Only the developer actually upgrading a third-party library needs to deal with open source version numbers, and everyone else can build on their work.
- lostcolony 11y ago"You'll need to document which version you pulled" - so now you're tasked with describing "I got this version" (be that git commit or whatever), rather than it being explicit as part of the package "This is (x) version". So you get to reimplement something yourself, in a non-portable, non-self-describing way. Such an improvement. Of course it could be done in a separate system. It could be done and tracked in a separate system even with version numbers. Go has just chosen to -require- you running your own package manager to make things stable, whereas for most languages it's optional and you can create a repeatable, portable build without it.