Breaking Change in v2.3

[yeldiRium]

What happened?

Why was apis/common (re-)moved in v2.3.0? That is a breaking change in a minor version.
This change is leading to significant problems in the entire ecosystem. The crossplane-runtime and any providers can only be upgraded together, since otherwise the providers would try to consume the removed types and dependencies updates/builds would fail.

Most providers do not suport >=v2.3.0 yet, but upbound/provider-aws does, although only by pinning an unreleased upjet version, which is also a problem, although a separate one.

This situation prevents projects from upgrading any component independently and blocks adoption of new features until all providers are migrated to >=v2.3.0 at the same time.

How could this happen?

[jbw976]

Hey there @yeldiRium, thanks for bringing this up and we do apologize for the hassles it's caused your development efforts.

Hopefully you've also seen the breaking change announcement in the v2.3.0 release notes, along with the full guide on how to update provider code bases step by step: https://github.com/crossplane/crossplane/releases/tag/v2.3.0. Of course, please let us know if anything is missing from that guide so we can improve it.

The whole reason driving this breaking change was that we needed to move the Crossplane CLI out of the core crossplane repo and into its own https://github.com/crossplane/cli repo as first described in crossplane/crossplane#4850. This required moving core crossplane APIs into its own dedicated module, and to prevent a circular dependency with crossplane-runtime, some of the runtime types moved into that APIs module as well as described in crossplane/crossplane#6998 and addressed in crossplane/crossplane#7019.

This could have been done in a crossplane v3 major bump, but we felt like that would not have properly set expectations about the amount of changes/churn and would probably cause more confusion for the community, given the precedence that was set with the major functional changes introduced in Crossplane v2, the only other time we've bumped the major version.

Once again, we know the changes are causing some confusion, but hopefully the release notes guide will be helpful for everyone.

This situation prevents projects from upgrading any component independently and blocks adoption of new features until all providers are migrated to >=v2.3.0 at the same time.

Just want to get some clarification on this statement - are you saying that you are not able to upgrade installed provider packages independently within a Crossplane control plane? Or are you instead saying that you can't independently bump provider module versions in scenarios where you are importing them as dependencies at compile time in a golang source code project?