> As an aside, since you're making the distinction, can you have meaningful benefit without breakage?
Sure, in two ways:
(1) Performance improvements with no semantic changes.
(2) New opt-in features that don't break existing code (such as where code using the new feature would have just been syntactically invalid in the old version, so the new feature won't conflict with any existing code.)
There be no reason for SemVer minor versions if you couldn't make meaningful improvements while maintaining full backward-compatibility.
I think I'm simply wrong here. I was envisioning "breaking" as being incompatible with Go1. If Go2 was a superset of Go1, it would be allow Go1 code to run flawlessly in Go2 and still allow any new keywords/features.
My assumptions were incorrect, and writing my reply to you sussed it in my head. Thank you for your reply, sorry for wasting your time :)
Sure, in two ways:
(1) Performance improvements with no semantic changes.
(2) New opt-in features that don't break existing code (such as where code using the new feature would have just been syntactically invalid in the old version, so the new feature won't conflict with any existing code.)
There be no reason for SemVer minor versions if you couldn't make meaningful improvements while maintaining full backward-compatibility.