Closed Kavindu-Dodan closed 7 months ago
All modified and coverable lines are covered by tests :white_check_mark:
:exclamation: No coverage uploaded for pull request base (
main@6f71fe4
). Click here to learn what that means.:exclamation: Current head a5467f8 differs from pull request most recent head cc68648. Consider uploading reports for the commit cc68648 to get more accurate results
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Why GO 1.19 and not go 1.20? End of life of 1.19 was 5 month ago.
@Kavindu-Dodan we can't mark this as feat!
, it will force a 2.0 which is really nasty to deal with. We can consider upgrading the min version OFF of unsupported go version non-breaking.... but I agree we should go to 1.20 I think.
@Kavindu-Dodan we can't mark this as
feat!
, it will force a 2.0 which is really nasty to deal with. We can consider upgrading the min version OFF of unsupported go version non-breaking.... but I agree we should go to 1.20 I think.
Good point. Yes I remember this happening before.
Still I think conventional commit messages and titles are valuble. Shall we attempt this strategy where we can enforce release version through main branch commit - https://github.com/googleapis/release-please/tree/main?tab=readme-ov-file#how-do-i-change-the-version-number ?
Otherwise I will revert the title :)
Why GO 1.19 and not go 1.20? End of life of 1.19 was 5 month ago.
Agree. I did not want to bump two major versions and this is why the update to 1.19. Soon I think we will update to 1.20 :)
@Kavindu-Dodan we can't mark this as
feat!
, it will force a 2.0 which is really nasty to deal with. We can consider upgrading the min version OFF of unsupported go version non-breaking.... but I agree we should go to 1.20 I think.Good point. Yes I remember this happening before.
Still I think conventional commit messages and titles are valuble. Shall we attempt this strategy where we can enforce release version through main branch commit - https://github.com/googleapis/release-please/tree/main?tab=readme-ov-file#how-do-i-change-the-version-number ?
Otherwise I will revert the title :)
I think you should just revert the title, I think people will not be surprised to see this support drop and it will show up clearly in the release notes (just my 2c).
People using GO are migrating easily to other version I am not sure a new major version is needed. Especially because if GO version is not compatible go will not let you update it in your go.mod so no risk to build something not compatible.
@Kavindu-Dodan we can't mark this as
feat!
, it will force a 2.0 which is really nasty to deal with. We can consider upgrading the min version OFF of unsupported go version non-breaking.... but I agree we should go to 1.20 I think.Good point. Yes I remember this happening before. Still I think conventional commit messages and titles are valuble. Shall we attempt this strategy where we can enforce release version through main branch commit - https://github.com/googleapis/release-please/tree/main?tab=readme-ov-file#how-do-i-change-the-version-number ? Otherwise I will revert the title :)
I think you should just revert the title, I think people will not be surprised to see this support drop and it will show up clearly in the release notes (just my 2c).
Done ✅
People using GO are migrating easily to other version I am not sure a new major version is needed. Especially because if GO version is not compatible go will not let you update it in your go.mod so no risk to build something not compatible.
@thomaspoignant agree and we are not making a major release. I have updated the title to avoid trigger this.
Beside, I created https://github.com/open-feature/go-sdk/issues/253 to track 1.20 upgrade. I think we should do this towards end of February 2024.
This PR
Update Go version from
1.18
to1.19
.Go 1.22 rc2 is alrady out and this is an attempt to gradually upgrade to go 1.20, keeping support for the last two major versions.