Mono-repo inter dependencies

[MarquessV]

Consider a repo with three packages:

[packages.common]
versioned_files = ["common/Cargo.toml"]
changelog = "common/CHANGELOG.md"
scopes = ["common"]

[packages.package-that-uses-common]
versioned_files = ["package-that-uses-common/Cargo.toml"]
changelog = "package-that-uses-common/CHANGELOG.md"
scopes = ["package_that_uses_common"]

[packages.another-package-that-uses-common]
versioned_files = ["another-package-that-uses-common/Cargo.toml"]
changelog = "another-package-that-uses-common/CHANGELOG.md"
scopes = ["another_package_that_uses_common"]

In this case, it's possible to update package-that-uses-common and another-package-that-uses-common independently from the other packages, so they should be versioned separately.

However, updates to common should always update both other packages. Therefore, anytime common needs to be version bumped, so should both of the sub-packages.

Currently, if we were to publish a commit like fix(common): ... then knope would bump common without bumping the dependent packages (both the common dependency and the version of each dependent). This makes it impossible to build and release the other packages without manual intervention or a complex workflow. One could add the common scope to each sub-package, but then changes to common are duplicated across each changelog.

There are other intricacies with this:

1. How should knope recognize these dependencies?
2. What if common gets a breaking change? Should knope just assume it'll work with the dependent packages and bump it anyways?
3. This probably isn't always the desired use case, so how should users be allowed to opt in or out?

[notmgsk]

This might be a duplicate of #195

[dbanty]

There's a lot of complexity here, because dependency updates can mean different things in different circumstances.

If the dependency is not part of the public API, then it might be a chore commit for that package (e.g., chore(package_that_uses_common): Bump common to 1.2.3) or might require no update at all (e.g., package-that-uses-common has a range of acceptable common versions—say >1,<2).

Then, in some languages like Python, narrowing a dependency range is a breaking change always, but multiple major versions can be included in a range. In Rust, narrowing a dependency range is only a breaking change if that package is used in the public API, but multiple major versions cannot be included. So selecting chore vs chore! to bump the dependent package is hard to solve.

There is also Renovate/Dependabot we can lean on for some of this... depending on the scenario.

We could try to represent these relationships somehow in knope.toml but I think it will get pretty yucky. To stay sane, since I don't think we'll find and account for every edge case in one pass, I think we should target very specific use cases to start with.

To that end, is there a specific case we can start with where things don't "just work" as-is with Renovate and solve just that, for now, to get started? E.g., some Cargo workspace problem where CI starts failing once versions are updated of only a single package?

[dbanty]

Converting to a discussion so we can have threads for specific use cases & problems—each of which could become its own issue 😁