| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +2 |
Thanks. I left optional suggestions, but feel free to leave out any that don't work out well.
`go mod init` now sets a lower `go` version in new `go.mod files`. `go mod init`Slighly misplaced \`? Probably should go be "`go.mod` files".
`go mod init` now sets a lower `go` version in new `go.mod files`. `go mod init`(nit) Maybe s/sets/defaults to/ here, if that helps put slightly more emphasis on the fact that this is only the default initial value, and so whenever the default value isn't a good fit, users can set it to fit their needs.
specifying the Go version `go 1.N-1.0`. Pre-release versions of `1.N` willWould it be more readable written as `go 1.(N-1).0`? Without brackets, it might be misread as a range between 1.N and 1.0.
Up to you, since adding brackets may have reduce readability in some other way. If you do change it here, also change it on the next line with N-2.
release candidates will create `go.mod` files with `go 1.24.0` and releasesMaybe expand to: ", Go 1.26.0 and its minors releases will ..."
the creation of modules that are compatible with currently supported versions of Go.What do you think of adding a sentence after this as a remindinder of how it's easy to do `go mod init example.com && go get g...@1.26rc1` if there's ever a need to set the version explicitly? Something like:
For additional control over the `go` version in new modules, `go mod init` can be followed up with [`go get go@version`](https://go.dev/doc/toolchain#get).
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |