The statement "Especially that of a previously compiled program will run under a new compiler version with the same behaviour” is not true with many platforms. Even with Java, with a great backwards guarantee, this is not the case (i.e. running on a later JVM) - although this is a somewhat recent behavioral change.
I said to add a “breaking changes” to the release notes. If you are upgrading your compiler/stdlib version, and rebuilding the software, it would be the builders responsibility to check that. Even if the end user knew it was a Go program, they probably can’t build it, and/or would not know how to add runtime options to work around it. > On Aug 27, 2024, at 11:06 AM, Creaky <whatexerc...@gmail.com> wrote: > > > > 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 > > <applewebdata://0FC112E6-3167-4DBB-B162-9D982CEDAEF5>> wrote: > > > > On Mon, Aug 26, 2024 at 2:28 PM robert engels <ren...@ix.netcom.com > > <applewebdata://0FC112E6-3167-4DBB-B162-9D982CEDAEF5>> wrote: > >> > >> Isn’t the version release notes > >> shttps://pkg.go.dev/net/http#Request.Hostufficient > >> <http://pkg.go.dev/net/http#Request.Hostufficient>? Maybe add a "breaking > >> changes" section? https://tip.golang.org/doc/go1.23 > >> <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 > <mailto: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 > > <https://groups.google.com/d/msgid/golang-nuts/e728d646-3baa-4d26-a396-6cb741b864b5n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/AD552B33-6DA5-40D0-8276-5098AEAB38EF%40ix.netcom.com.
