4 ms·
To be fair, this is true of pretty much any major release of a new piece of software: tread lightly and test carefully before deploying to production. The new
by rsc 11y ago
To be fair, this is true of pretty much any major release of a new piece of software: tread lightly and test carefully before deploying to production.
The new GC, default GOMAXPROCS > 1, and changes to the scheduler may well expose latent bugs in code that worked fine in Go 1.4.
- vessenes 11y agoTotally. We've been mostly running tip for some time, and sending in bug reports when we can be useful, overall a big win for us, but not without its risks. :) Honestly, I could have seen rebranding 1.5 to 2.0; there are major under the hood changes you guys have made.
- rsc 11y agoI can see that, and I've been idly wondering over the past few days what the largest N will be for Go 1.N. The contrast with most version numbering, however, is that we've defined a meaning for Go 2: it breaks all your Go 1 programs. Being a Go 1.X release is actually a stronger statement about how your code will behave.
- andrewchambers 11y agoWaiting for the confusion when Go1 2.0 is released :). Or are you thinking of 1.10?
- tagrun 11y ago"Go1 2.0" is meaningless, Go X refers to Go X.Y.Z. Many FOSS programs treat X, Y and Z as numbers rather than digits, and increment X when there is a breaking change in the API or some serious restructuring/change (this is starting to change, recently we see programs incrementing major version periodically [most remarkably, Linux, Firefox, GCC have jumped on this bandwagon], these days only FOSS libraries are seriously sticking to that.) so yeah, it's probably going to be 1.10 and so on.
- duaneb 11y agoI would hope that 1.5 to 2.0 would have some semantic changes to the language as opposed to just implementation tooling. I've learned not to even ask about type improvements. :(
- deleted 11y ago[deleted]