Arthur Diniz <[email protected]> writes: > 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.
Yes. I think this is what we all are converging on it the best recommended practice going forward. > 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. Yes, it is a pain and adds extra overhead. As far as I understand, the other options has more pains and overhead. When it is FEASIBLE to update a v4 package to v6 without a source package rename, I think that is the right thing to do. We don't need to introduce -v6 packages just because. Sometimes upgrading a v4 to v6 goes painlessly and there is just one or two reverse dependencies that can easily be fixed. But when it doesn't, we are often stuck, and then introducing a v6 package is cheap compared to all the other costs. I see concerns when a v7 comes along, and there is a non-painless upgrade path from v6 to v7 - then why introduce a new v7-dev package? But this churn is rare, and on the whole perhaps it is worth that churn for consistency and simplicity in other tools. And we can always revert to a non-versioned source package name eventually too, and flip flop between these if there is a need. /Simon
signature.asc
Description: PGP signature
