Skip to content

chore(deps): refresh all dependencies with go get -u - #60

Open
pigri wants to merge 1 commit into
mainfrom
chore/go-get-u
Open

chore(deps): refresh all dependencies with go get -u#60
pigri wants to merge 1 commit into
mainfrom
chore/go-get-u

Conversation

@pigri

@pigri pigri commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Pre-release dependency refresh: go get -u ./... across the whole module graph, then go mod tidy. Follows #58, which only moved the five versions Dependabot had already proposed.

Direct dependencies

Module From To
oschwald/maxminddb-golang/v2 v2.4.1 v2.5.0
prometheus/client_golang v1.24.0 v1.24.1
stretchr/testify v1.11.1 v1.12.1
k8s.io/api v0.36.3 v0.37.0
k8s.io/apimachinery v0.36.3 v0.37.0
k8s.io/client-go v0.36.3 v0.37.0

go-logr/logr, maxmind/mmdbwriter, gateway-api, controller-runtime and sigs.k8s.io/yaml were already current.

Notable indirect: go.uber.org/zap v1.28.0, prometheus/common v0.71.0, prometheus/procfs v0.22.0, go-openapi/swag v0.29.1, fsnotify v1.10.1, apiextensions-apiserver v0.37.0, kube-openapi, and golang.org/x/{net,sync,term,text}.

Only go.mod and go.sum change; no source changes were required.

Read this before merging: k8s is now a minor ahead of controller-runtime

sigs.k8s.io/controller-runtime stays at v0.24.1 — not an oversight, that is the newest published release (go list -m -versions ends there). Its own go.mod requires k8s.io/{api,apimachinery,client-go} v0.36.0, so after this change MVS resolves the k8s libraries one minor ahead of what controller-runtime was built and tested against.

What that is and is not backed by:

  • It compiles — no API surface breakage.
  • The suite passes, and these tests drive controller-runtime's fake client, so the scheme, object tracker and apimachinery paths do get exercised against the newer libraries.
  • There is no envtest in this repo, so nothing here exercises a real API server. Behavioural skew in the client/RESTMapper layer would not be caught by this run.

If that risk is not wanted in a release, hold the k8s line at the controller-runtime-matched version and keep every other bump:

go get k8s.io/api@v0.36.3 k8s.io/apimachinery@v0.36.3 k8s.io/client-go@v0.36.3 && go mod tidy

Verification

Run locally on go1.26.0:

  • go mod tidy — clean, no further changes
  • go build ./... — ok
  • go vet ./... — clean
  • go test ./... — all packages pass (synapse-operator, synapse-operator/controllers)

Pre-release dependency refresh across the whole module graph, not just
the pinned direct bumps.

Direct dependencies:

- github.com/oschwald/maxminddb-golang/v2 v2.4.1 -> v2.5.0
- github.com/prometheus/client_golang v1.24.0 -> v1.24.1
- github.com/stretchr/testify v1.11.1 -> v1.12.1
- k8s.io/api v0.36.3 -> v0.37.0
- k8s.io/apimachinery v0.36.3 -> v0.37.0
- k8s.io/client-go v0.36.3 -> v0.37.0

Notable indirect: go.uber.org/zap v1.28.0, prometheus/common v0.71.0,
go-openapi/swag v0.29.1, fsnotify v1.10.1, golang.org/x/{net,sync,term,
text}, k8s.io/apiextensions-apiserver and kube-openapi.

sigs.k8s.io/controller-runtime stays at v0.24.1 -- that is the newest
release, and it is built against k8s.io/* v0.36.0, so the k8s libraries
now sit one minor ahead of the version controller-runtime pins. The
module builds and the full test suite passes against the newer set.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant