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

[Arthur Diniz]

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:

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

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: 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