Re: golang-k8s-sigs-structured-merge-diff 6.x: how should we handle the v4 -> v6 major bump?

[Arthur Diniz]

Hi all,






What I've done so far:

1. Filed the ITP for the new package:
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146429


  - flight-deck MR:
     https://salsa.debian.org/go-team/flight-deck/-/merge_requests/111
  - Repository:

https://salsa.debian.org/go-team/packages/golang-k8s-sigs-structured-merge-diff-v6


   The rationale for the separate source package is recorded in
   debian/README.source.





https://salsa.debian.org/go-team/packages/golang-k8s-sigs-structured-merge-diff-v6/-/merge_requests/1

Thanks,
Arthur Diniz

[1] https://lists.debian.org/debian-go/2026/08/msg00202.html
[2] https://lists.debian.org/debian-go/2026/09/msg00000.html

On 31/08/2026 22:49, Arthur Diniz wrote:

Following up on the earlier thread about the sigs.k8s.io/structured-merge-diff module-path bump [1][2], here's where things stand. As discussed, I went with packaging /v6 as a separate source package so it can coexist with the existing v4 package during the transition, rather than bumping v4 in place. 2. Created the packaging repository under the go-team Salsa group (via flight-deck): 3. Opened an MR against that repository with the initial packaging (6.4.2-1). Before I upload to NEW, I'd appreciate a review from the team, just to get another pair of eyes on the changes. If someone has a moment to look over the initial-packaging MR, I'll incorporate any feedback and then proceed with the upload.

Hi team,




Background
==========



     old: module sigs.k8s.io/structured-merge-diff
     new: module sigs.k8s.io/structured-merge-diff/v6

Reverse dependencies still import the old paths, e.g.:

     sigs.k8s.io/structured-merge-diff/v4/value
     sigs.k8s.io/structured-merge-diff/v4/schema
     sigs.k8s.io/structured-merge-diff/v4/fieldpath

so they fail to build against the new package with errors like:

     cannot find package "sigs.k8s.io/structured-merge-diff/v4/value"
     in any of: ... (from $GOROOT) ... (from $GOPATH)


What I tried: a v4 compatibility symlink
=========================================







- https://debusine.debian.net/debian/developers/work-request/1204461/

The current migration excuses confirm the regressions:

I'd like some advice on how to migrate golang-k8s-sigs-structured-merge diff from 4.6.0 to 6.3.0, which Simon uploaded to experimental. The new upstream is needed by more recent golang-k8s-apimachinery (and the wider Kubernetes stack I'm trying to bump), but it breaks the reverse dependencies and I want to agree on a strategy before pushing anything to unstable. The problem is a Go semantic-import-versioning change. Upstream moved the module path in go.mod: I attempted to keep the single source package and provide backwards compatibility via a symlink, so that the old v4 import paths resolve into the v6 source tree (the on-disk layout of value/, schema/, fieldpath/ is unchanged between the two versions). Concretely, in the - dev package:     usr/share/gocode/src/sigs.k8s.io/structured-merge-diff/v4 -> .../ structured-merge-diff/v6 The symlink strategy did not fix, several revdeps still fail their autopkgtests: https://qa.debian.org/excuses.php?experimental=1&package=golang-k8s- sigs-structured-merge-diff

- containerd/2.1.9+ds1-1
- glab/1.53.0-1
- golang-github-in-toto-go-witness/0.10.0-3
- golang-k8s-apimachinery/0.33.4-2
- golang-k8s-client-go/0.33.4-1
- golang-k8s-kube-openapi/0.0~git20241212.2c72e55-4

A symlink can only work over the import path; but it cannot



Options I can see
=================





What worries me are in particular:

- containerd
- glab









I'm also open to other ideas I haven't thought of.

Thanks,
Arthur Diniz

absorb genuine API differences between v4 and v6, which is what some of these revdeps are actually hitting. 1. Push the v6 upload through (unstable) and then fix the failing revdeps one by one. The k8s-* packages (apimachinery, client-go, kube-openapi) I maintain, so those are tractable. These may be harder to migrate to v6, and I'd rather not force breakage on them. 2. Introduce a separate source package for v6 (e.g. keep golang-k8s- sigs-structured-merge-diff at v4 and add golang-k8s-sigs-structured- merge-diff-v6, shipping the /v6 import path), so both major versions coexist in the archive during the transition. This lets us migrate the packages to v6 without breaking v4 consumers, at the cost of maintaining two source packages until the v4 consumers are gone. I'm leaning towards option 2 because it decouples the Kubernetes bump from the schedule of unrelated other revdeps like containerd and glab, but I'm not sure it's worth the extra packaging overhead and I'd like to hear whether the team has a preferred convention for this in Go packaging.

OpenPGP_signature.asc
Description: OpenPGP digital signature