3 ms·

Go and Versioning: Reproducible, Verifiable, Verified Builds

• codehusker 9y ago
  I found myself getting lost among the various posts by rsc and the resulting HN discussions, I hope this helps someone else too. All of the posts in this series on vgo are listed here: https://research.swtch.com/vgo https://research.swtch.com/vgo. There will be at least one more, a FAQ on Friday. And the most popular HN discussions about them (in chronological order): https://news.ycombinator.com/item?id=16421966 https://news.ycombinator.com/item?id=16421966 (Go += Package Versioning) https://news.ycombinator.com/item?id=16431299 https://news.ycombinator.com/item?id=16431299 (Semantic Import Versioning) https://news.ycombinator.com/item?id=16433425 https://news.ycombinator.com/item?id=16433425 (Minimal Version Selection)
  • deleted 9y ago
    [deleted]
  • vanderZwan 9y ago
    You can also click on the (swtch.com) behind the link to see all other posts linking to that site: https://news.ycombinator.com/from?site=swtch.com https://news.ycombinator.com/from?site=swtch.com
• deleted 9y ago
  [deleted]
• infogulch 9y ago
  This addresses the biggest holdout I had so far: verifying that tagged releases don't change from underneath you, by checking against a Certificate Transparency-like local log of all encountered module versions and their hash. As I understand it, go verify checks the local go.modverify file against all transitive dependencies. It might be valuable to also check those against the dependencies' go.modverify files as well (if present), to make sure everyone is on the same page on what each version represents.