feat!: upgrade Go to 1.18 #140
Conversation
|
Should this be considered a breaking change? Should we increment the major version? I've specifically seen other Go packages NOT do this when upgrading their version, but I also found it a bit annoying. @skyerus @davejohnston @james-milligan @Kavindu-Dodan @justinabrahms @agentgonzo thoughts? |
|
My thoughts are that as we’re not using anything that breaks backwards compatibility for now (e.g. generics), this isn’t technically breaking. However, this means that if we introduce something that does break the backwards compatibility later down the line we must remember to mark it as breaking. Perhaps it’s simpler to just mark it as breaking now and be done with it. |
|
Regarding versioning, I think it is safe to go for a Major release, thus giving maintainers freedom to fully utilize this upgrade and to include new language features incompatible with 1.x releases. |
|
It appears that the consensus is to make this a breaking change |
Signed-off-by: Skye Gill <[email protected]>
skyerus
force-pushed
the
issue-12_go1.18
branch
from
0a67bee
to
9e62d0e
Compare
This PR
Upgrades Go to 1.18
Related Issues
Fixes #12
Notes
Follow-up Tasks
How to test