Request for tips: how to handle product life cycle with mono_repo? about mono_repo.dart HOT 1 OPEN

2. doesn't necessarily mean that at that revision all the other packages in the repo are compatible with build_runner_core @ that revision -> I drew the conclusion that the in the repo packages have their own life/release-cycle

Correct, although most of the time packages within that repo are cross compatible because we have integration test that use path dependencies on all of them to run tests.

how you handle development. Hypothetical scenario (that kind of happened to me with package:build) is that I would like 1 package at a specific revision (tag) and have all the other packages at such a state that works well with that specific revision (eg. based on pubspec.lock file).

Yeah it's common to make a quick local edit to a pubspec.yaml to flip between path and hosted dependencies and then running a pub get to resolve things.
We've left this entirely up to manual processes and it has generally worked out OK for us. @jakemac53 or @kevmoo might have different opinions on that part.

I was thinking on having multiple working copies and do sparse checkouts for package directories. That way the repository could remain a mono repo while locally I can handle different revisions/package version independently from each-other.

I only ever make full working copies - I don't bother with partial copies. Often I won't bother with a pub get in most of the package directories, but it's still an entirely manual process and I sometimes need to double check that I've done a pub resolve since the last time I change deps.

from mono_repo.dart.