chore: Bump required Go version to 1.18 #650

mvdkleijn · 2024-02-15T13:41:56Z

mvdkleijn commented

2024-02-15 13:41:56 +00:00

Reasoning for the bump:

Enforce (instead of assume) use of newer Go version to ensure presence of security fixes
Enable use of more recent language features
Go < 1.21 is EOL
Testing workflow already uses >= 1.20

For sec fixes, see: https://go.dev/doc/devel/release#go1.21.minor

Signed-off-by: Martijn van der Kleijn martijn.niji@gmail.com

Reasoning for the bump: - Enforce (instead of assume) use of newer Go version to ensure presence of security fixes - Enable use of more recent language features - Go < 1.21 is EOL - Testing workflow already uses >= 1.20 For sec fixes, see: https://go.dev/doc/devel/release#go1.21.minor Signed-off-by: Martijn van der Kleijn <martijn.niji@gmail.com>

mvdkleijn added 1 commit 2024-02-15 13:41:57 +00:00

chore: Bump required Go version to 1.21.5

Reasoning for the bump:
- Enforce (instead of assume) use of newer Go version to ensure presence of security fixes
- Enable use of more recent language features
- Go < 1.21 is EOL

For sec fixes, see: https://go.dev/doc/devel/release#go1.21.minor

Signed-off-by: Martijn van der Kleijn <martijn.niji@gmail.com>

testing / testing (pull_request) Has been cancelled

Details

8144dcf23d

techknowlogick commented

2024-02-20 00:01:55 +00:00

Thank you for your PR, we have an older version listed there as it allows the SDK to be included in software that isn't built with the lastest/stable version of go. Although, as you pointed out 1.13 is quite old (released in 2019), there are some downstream operating systems that still use older versions. I think we could probably safely jump to 1.18, which was released just shy of 2 years ago, as that is a balance between newness, and being included in still supported OSes. Of course, the recommendation from the project is to also build your project using a stable version of go, which this would still allow as even if the version in go.mod is low, that doesn't prevent it from being built with newer versions of go.

mvdkleijn added 1 commit 2024-02-21 09:49:25 +00:00

Downgrade to go 1.18 after PR feedback

testing / testing (pull_request) Failing after 1m56s

Details

24c6b7f5ce

mvdkleijn commented

2024-02-21 11:18:49 +00:00

Thank you for your PR, we have an older version listed there as it allows the SDK to be included in software that isn't built with the lastest/stable version of go. Although, as you pointed out 1.13 is quite old (released in 2019), there are some downstream operating systems that still use older versions. I think we could probably safely jump to 1.18, which was released just shy of 2 years ago, as that is a balance between newness, and being included in still supported OSes. Of course, the recommendation from the project is to also build your project using a stable version of go, which this would still allow as even if the version in go.mod is low, that doesn't prevent it from being built with newer versions of go.

Hi @techknowlogick

While I understand your reasoning, I can't say I personally agree. I believe it is better to support only the officially supported releases of Go. While I'm sure there are systems compiled against the go-sdk, I think that only supporting the officially supported go releases is a good motivator for people to bump their systems versions.

The problem really only exists if people re-compile their project and if they do that, I firmly believe they should be attending to maintenance issues, like bumping their go versions. That's just good practice IMHO.

In any case, any bump is better than no bump so I've adjusted this PR to use 1.18 as you indicated.

> Thank you for your PR, we have an older version listed there as it allows the SDK to be included in software that isn't built with the lastest/stable version of go. Although, as you pointed out 1.13 is quite old (released in 2019), there are some downstream operating systems that still use older versions. I think we could probably safely jump to 1.18, which was released just shy of 2 years ago, as that is a balance between newness, and being included in still supported OSes. Of course, the recommendation from the project is to also build your project using a stable version of go, which this would still allow as even if the version in go.mod is low, that doesn't prevent it from being built with newer versions of go. Hi @techknowlogick While I understand your reasoning, I can't say I personally agree. I believe it is better to support only the officially supported releases of Go. While I'm sure there are systems compiled against the go-sdk, I think that only supporting the officially supported go releases is a good motivator for people to bump their systems versions. The problem really only exists if people re-compile their project and if they do that, I firmly believe they should be attending to maintenance issues, like bumping their go versions. That's just good practice IMHO. In any case, any bump is better than no bump so I've adjusted this PR to use 1.18 as you indicated.

6543 approved these changes 2024-02-22 21:25:39 +00:00

6543 changed title from ~~chore: Bump required Go version to 1.21.5~~ to chore: Bump required Go version to 1.18

2024-02-22 21:27:59 +00:00

6543 merged commit 001d5fad51 into main

2024-02-22 21:28:11 +00:00

6543 referenced this issue from a commit

2024-02-22 21:28:12 +00:00

chore: Bump required Go version to 1.18 (#650)

Sign in to join this conversation.

No reviewers

No Milestone

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/go-sdk#650