On Tuesday, August 27, 2024 at 8:00:27 AM UTC+10 robert engels wrote:
I don’t think being concerned about the user is correct - I suspect that many (most?) of the users have no idea the program is even written in Go… This is a builders responsibility imo to either fail at start-up with a user understandable error, add mitigating code, or don’t build and release using the latest release. > On Aug 26, 2024, at 4:45 PM, Ian Lance Taylor <ia...@golang.org> wrote: > > On Mon, Aug 26, 2024 at 2:28 PM robert engels <ren...@ix.netcom.com> wrote: >> >> Isn’t the version release notes shttps:// pkg.go.dev/net/http#Request.Hostufficient? Maybe add a "breaking changes" section? https://tip.golang.org/doc/go1.23 > The Go ecosystem has created the expectation that a compiled program will run correctly. Especially that of a previously compiled program will run under a new compiler version with the same behaviour. Breaking changes that change the contract of behaviour continuity needs special mentioning and highlighting. Changing defaults is one such change. A builder may not be cognisant of the significance or impact of a release note entry. Especially when the breaking behaviour is not noted or requires extensive understanding of a specialist technical area. The users impacted (or I prefer audience set) can be broad. From programmers, deployers, administrators to end users. A good portion of the audience set will have the capability to know it is a Go program at fault. The key is discoverability of the issue's cause and fix. Good documentation and clear communications aids in this. For breaking changes, the audience needs the ability to find a solution and communication needs to support easy discovery of said solution. The current single line Release note entry is insufficient for meeting the need of easy discovery. Practices I have seen to address discoverability includes identifying breaking changes separately, often in its own document. Usually with a link to an accompanying technical note, bulletin or blog. The accompanying document then describes the change in detail including: - Summary of what the change is. - Reason for change. - Impact of change, what breaks and how to identify it. - Various solutions or fixes to restore behaviour. With source code or just with executable. - Commitment to support or provide continuity for said solutions or fixes. Increasing the easy of discovery helps everyone in the ecosystem. Regards, Creaky -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e728d646-3baa-4d26-a396-6cb741b864b5n%40googlegroups.com.
