Hacker News Reader

Comment by vhbit | Hacker News Reader

> The lock file stops future upgrades; once it is written, your build stays on serde 1.0.27 even when 1.0.28 is released.

That means that the only difference is that `vgo` doesn't require lock file for reproducible builds, now the question is what's considered so terrible wrong/dangerous with having a lock file?

View on HN

If there was a security fix in a package, MVS allows build infra to automatically upgrade (assuming packages imported are well maintained by their owners) where as lock-files require manual intervention.

Imagine the packaging and development ecosystem in internet scale.

I'm not sure what this is asserting. There's no association between MVS and build infra. If you have a security fix to apply, you'd run `vgo get -u` to upgrade all your modules; systems like Cargo that use lockfiles would run `cargo upgrade`. This is just as automatic. In fact, vgo is less automatic here because systems like Cargo allow users to decide when they want certain upgrades automatically, which means that new downstream users can get the security fix even without needing to explicitly upgrade. And vgo also requires more manual intervention to upgrade than traditional build systems, because if the upgrade requires a major version bump then you also have to edit the import statements in your source files as well. vgo is both less automatic and requires more manual labor; that appears to be an intentional choice on behalf of the vgo manifesto.

> if the upgrade requires a major version bump then you also have to edit the import statements in your source files as well

As per vgo blog posts, this scenario is not an Upgrade, but replacing one package with another package. A package is uniquely identified by it's import path, so if major version is changed, import path changes, so it is not same package.

Reply on news.ycombinator.com