Skip to content

chore(deps): bump go to 1.26.3 in all go.mod files #27772

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
reggie-k wants to merge 1 commit into from
Closed

chore(deps): bump go to 1.26.3 in all go.mod files #27772

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion gitops-engine/go.mod
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
module github.com/argoproj/argo-cd/gitops-engine

go 1.26.1

@rumstead rumstead May 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just leave this as 1.26?

go 1.26.3

require (
github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc
Expand Down
2 changes: 1 addition & 1 deletion go.mod
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ module github.com/argoproj/argo-cd/v3

// Do NOT bump this unless we use features that are only available on the new version.
// If you want to update the BUILD version, just update go versions in the release workflows.
go 1.26.1
go 1.26.3

@olivergondza olivergondza May 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the commit above, what is the motivation for bumping it in this case?

@ppapapetrou76 ppapapetrou76 May 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I was wondering also about this comment myself - not sure why it's there and why it's. problem to bump this version.....

@olivergondza olivergondza May 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a problem for anyone consuming some of these as a library. Upgrading the go requirement leads to a cascade of upgrades in dependant components. Hence the appeal on bumping it only when there is a pragmatic motivation.

Full disclaimer: Me employer in one such party.

@reggie-k reggie-k May 11, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this comment is more relevant for cherry-picking Go bumps into an existing minor release - because it may be problematic to people that use Argo CD library to experience a breaking change upon an Argo CD patch release.
I think is is justified upgrading this for a new Argo CD minor release, even if at this point in time we don;t use any new language version features - because when we'd need to do so, cherry-picking the change into an existing minor release will result in a much poorer user experience.
@crenshaw-dev WDYT?

@crenshaw-dev crenshaw-dev May 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when we'd need to do so, cherry-picking the change into an existing minor release will result in a much poorer user experience

I'm not sure I follow... is the idea that we should have master require the latest possible go release so that when we cherry-pick changes, it's more likely that the old release branch is on a new enough version to support the cherry-picked changes?

I think that's kind of low benefit for the cost of library users having to constantly upgrade go versions. I don't see changes cherry-picked very often that use such new go features that the cherry pick fails.

@rumstead rumstead May 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we just leave this as 1.26 with no patch version?

@rumstead rumstead May 12, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, this may not work https://go.dev/doc/toolchain#version. That means if any of our dependencies declare a version > 1.26 (eg 1.26.0+) it will require us to update our go.mod.

@crenshaw-dev crenshaw-dev May 12, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, the requirements stack. Which is why we shouldn't bump to latest, it makes us a bad neighbor. I'd default to 1.x.0 any time we don't have a good reason to bump that last digit (which should be almost always, since go has really strong compatibility guarantees).


require (
code.gitea.io/sdk/gitea v0.23.2
Expand Down
2 changes: 1 addition & 1 deletion hack/get-previous-release/go.mod
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
module github.com/argoproj/argo-cd/get-previous-release

go 1.26.1
go 1.26.3

require (
github.com/stretchr/testify v1.9.0
Expand Down
Loading