3 ms·
I still remain unconvinced at the lack of lockfiles. I’m in complete agreement with rsc the minimum version algorithm produces more reliable builds, ie version
by bbatha 9y ago
I still remain unconvinced at the lack of lockfiles. I’m in complete agreement with rsc the minimum version algorithm produces more reliable builds, ie version selection is deterministic. However, lockfiles do more than select versions deterministically, they also hash the packages so that you can be guaranteed that version 1.1 today is the same as 1.1 tomorrow.
I also have philosophical concerns about selecting the minimum version: people release patch versions for a reason. I hope vgo only uses the minimum for minor versions not patches (even then I still prefer the newest minor — most of the fixes I release are not back ported as patches). However, I don’t think this algorithm is a bad choice and it seems to fit the go philosophy nicely as it’s simple and to make it “better” gets into many thornier issues that may even involve language changes ala project jigsaw for Java.
- uluyol 9y agoI don't see why hashing is incompatible with the minimum version algorithm. As far as I can tell, the algorithm will always pick versions that are specified in one module file unless a version that doesn't exist was added by hand. If the algorithm always selects a version specified in modules, then that's a perfectly good place to put hash values. This should probably be addressed explicitly, but it's only been what, 1 day, since vgo was announced?
- bbatha 9y agoIt’s not. But it’s not in the current tool. And as this article devoted a long section to why they’re not required for reproducibility I suspect the go team isn’t planning on added one. It’s especially important to give this feedback early in the process so this critical functionality of the tool is not omitted.