Maintenance and support for Go major versions

[nodivbyzero]

This continues the discussion from #1339 regarding the maintenance and support of major versions.

[nodivbyzero]

Here are a couple of suggestions:

1. Align the Go version with the one used in gin-gonic/gin, as specified in their go.mod file.
2. Include a section similar to the AWS SDK for Go V2 README https://github.com/aws/aws-sdk-go-v2/blob/2c8f69732f75e2400d41a5599ee8b50a78ba1ff0/README.md?plain=1#L18-L33.

[deankarn]

Been reading a lot about it, will find some time to type it all out this weekend but thinking language version shouldn't be considered a breaking change.

I realize that's spicy comment but when I get around to posting the reasoning I think it will make a little more sense; this is one of those there are pros and conns on both sides of it.

[zemzale]

I don't feel it's that spicy at all, since for the most part, when required most libraries jump to newer versions of golang without thinking twice about it.

I don't think we have to align with gin, but aligning with go release policies of supporting the two latest versions should be what we aim for.

[deankarn]

Hey All, sorry for taking so long to post, the wind storms in BC, power outages, cleanup and then the holidays sidelined me for a while 😅 here are my thoughts and reasonings.

Proposed Decision:

Just like the Go release policy Each major Go release is supported until there are two newer major releases we should support the latest two versions of Go (officially).

Reasonings & Musings

I do not believe that the minimum supported Go version (MSGV) falls under semver 2.0 for a bunch of reasons including, but not limited to:

1. Semver 2.0 applies to/covers the public interface/api and not behavioural nor MSGV.

2. Upping the MSGV is not a breaking change to existing builds that have pinned the library dependency version and change is opt-in. If the latest or latest major version is being used in such builds then are already accepting/opting-in to the changes and other inherent risks also not covering under semver 2.0 like behavioural changes.

3. Security & OS compatibility additions/fixes are not back ported to older Go versions.

4. Major version bumps in Go are very intrusive, even if 99% of the public interface didn't change because of the major version, beyond v1, is included in the imports themselves, which I've always disagreed with as it wasn't necessary. This seems like an easy sed command away, but in larger and distributed codebases is a significant effort in both time, but coordination as well.

Even IF the MSGV was considered a breaking change No. 3 above alone is a reason we should follow the Go release policy for support and bump without a major version bump anyways; Security & OS support trump Semver IMO.

Thanks all for reading, let me know your thoughts, this is the proposal I'm making.

[nodivbyzero]

Thanks for sharing your thoughts and the detailed reasoning behind the proposed decision. Your breakdown makes a lot of sense, especially in aligning with Go's release policy and prioritizing security and OS compatibility.

I particularly agree with your points about Semver 2.0 and how it applies more strictly to public interfaces/APIs rather than behavioral aspects or MSGV.

Overall, I think your proposal to officially support the latest two versions of Go is both pragmatic and in line with best practices. It ensures that we're supporting the ecosystem responsibly while also acknowledging the limitations of maintaining compatibility with older versions.

Looking forward to hearing others' thoughts as well!

[sonasingh46]

It makes sense to me as well to align to support the latest two version of Go

[sonasingh46]

Hey @deankarn @nodivbyzero -- Reading the thread, appears that we are in agreement on the proposal! I was wondering if we can have a release that fixes this critical CVE.
I have already raised a PR for this and I think @nodivbyzero have also raised one.
I am fine with going any of the PR. Let me know what you think and yes, happy to help if there is anything that I can do for the release.

[deankarn]

Ok so the decision has been made then. We officially support the latest two version of Go, aligning with Go's own release policy.

I have crafted a PR to document and increase the MSGV here.