Shifting dependency versions in same release branch causing downstream issues

[akutz]

What steps did you take and what happened:
There seems to be some module weirdness originating out of the Cluster API Upgrade Tool centered around the github.com/Azure/go-autorest package.

The upgrade tool pulls in k8s.io/[email protected]+incompatible which does not import autorest. However, autorest shows up several times as a transitive dependency for the upgrade tool:

$ cd $(mktemp -d) && \
  git clone https://github.com/vmware/cluster-api-upgrade-tool . && \
  go list -m -u all 2>/dev/null | grep autorest
github.com/Azure/go-autorest/autorest v0.9.0 [v0.9.2]
github.com/Azure/go-autorest/autorest/adal v0.6.0 [v0.8.0]
github.com/Azure/go-autorest/autorest/date v0.2.0
github.com/Azure/go-autorest/autorest/mocks v0.3.0
github.com/Azure/go-autorest/logger v0.1.0
github.com/Azure/go-autorest/tracing v0.5.0

The upgrade tool is inheriting the transitive dependency on autorest via the direct dependency on sigs.k8s.io/[email protected]:

$ cd $(mktemp -d) && \
  git clone https://github.com/kubernetes-sigs/cluster-api . && \
  git checkout -b v0.2.1 v0.2.1 && \
  go list -m -u all 2>/dev/null | grep autorest
github.com/Azure/go-autorest/autorest v0.9.0 [v0.9.2]
github.com/Azure/go-autorest/autorest/adal v0.6.0 [v0.8.0]
github.com/Azure/go-autorest/autorest/date v0.2.0
github.com/Azure/go-autorest/autorest/mocks v0.3.0
github.com/Azure/go-autorest/logger v0.1.0
github.com/Azure/go-autorest/tracing v0.5.0

However, what happens when a downstream project imports both the upgrade tool and a newer version of Cluster API v1alpha2?

$ cd $(mktemp -d) && \
  git clone https://github.com/kubernetes-sigs/cluster-api . && \
  git checkout -b v0.2.5 v0.2.5 && \
  go list -m -u all 2>/dev/null | grep autorest
github.com/Azure/go-autorest v11.1.2+incompatible [v13.2.0+incompatible]

Conflict!

FWIW, the dependency on github.com/Azure/go-autorest is transitive via k8s.io/client-go.

Essentially, because Cluster API moves so quickly, and we're starting to see libraries, such as the upgrade tool, built on top of Cluster API, dependency conflicts are being created when downstream work wants to use both the most recent patch of Cluster API with a library built on top of Cluster API that still references an older version from the same release branch.

It makes me wonder if Cluster API should stop updating dependencies unless otherwise absolutely required during a release branch?

• Cluster API v0.2.1 depends on k8s.io/client-go v11.0.1-0.20190409021438-1a26190bd76a+incompatible
• Cluster API v0.2.5 depends on k8s.io/client-go v0.0.0-20190918200256-06eb1244587a

The result is a messy situation for people trying to use Cluster API and libraries built on top of Cluster API.

One thing we could do to combat this is to start adding comments to go.mod files such as:

// The following dependency was resolved from the tag "kubernetes-1.15.4"
k8s.io/client-go v0.0.0-20190918200256-06eb1244587a

With anything related to k/k, the above comment approach would simplify aligning all k/k related dependencies in a project that imports both Cluster API and libraries built on top of it.

What did you expect to happen:
A downstream consumer of Cluster API should be able to pull in a newer version of Cluster API from the same release branch, even when another dependency pulls in a different version of Cluster API from the same release branch.

cc @ncdc

[akutz]

/remove kind/bug

[ncdc]

I need to fix the upgrade tool's cluster-api version. We addressed this in the most recent releases of CAP*.

[ncdc]

Going forward, I would like to do a better job of staying on a fixed version of controller-runtime, controller-tools, client-go, apimachinery, etc., within a patch stream.

[akutz]

/remove-kind bug

[akutz]

Hi @ncdc,

Thanks! Yeah, my concern is the going forward part -- hence the suggestion of the comments to make things easier for downstream consumers. But even then it will be tough to catch these as CAPI and its ecosystem grows. I wonder if some job should be set up to ensure there are no graph conflicts across a specified number of related repositories?

[vincepri]

/area dependency
/area release

I'm not sure if this issue is directly actionable, it seems we might need a policy written somewhere in the repository, but that might be a different issue

[ncdc]

We should write/update a reviewers guide around expectations within a patch stream.

[ncdc]

/lifecycle active