3 ms·
I admit I wasn't bit by these changes and had a much better experience overall. Thank you for the long write-up. However, I think you only mentioned changes in
by cube2222 5y ago
I admit I wasn't bit by these changes and had a much better experience overall. Thank you for the long write-up.
However, I think you only mentioned changes in major releases, whereas in this scenario (vulnerability fix) a minor release would suffice (the parent mentioned updating to a point release of a library). Did you also have issues with minor releases?
- staticassertion 5y ago> a minor release would suffice Does the Go compiler have LTS releases? Like if I'm on 1.0, but 1.5 is out, are they going to release a 1.0.1 for a vuln that impacts 1.0+ ? It seems unlikely but I'd be curious to know. Libraries release patches more frequently, and it's also generally easier to apply a patch yourself if you need to. Otherwise a point release may still imply a major release.
- cube2222 5y agoThe most recent 2 major releases get the fix in case of security issues[0]. This means you can be up to 6 months behind the newest release to never be forced to do a major version update under time pressure. [0]:https://github.com/golang/go/wiki/MinorReleases https://github.com/golang/go/wiki/MinorReleases
- staticassertion 5y agoThanks that's pretty solid.
- TheDong 5y agoIt's true that minor releases have been much less rocky, but I think the overall point that upgrading a lot of things at once is more annoying than updating a smaller number of things at once still holds. It's unlikely a fuzzing library has a security issue anyway since it's for test code, so the more pragmatic concern is that new fuzzing features may be adopted slowly because i.e. the feature requires go 1.20, but go 1.20 broke some part of net/http for the 10th time.