4 ms·

> And if you’re trying to skirt Conway, having multiple teams sharing a single deployable, you’re gonna have a bad time. Because good luck getting all teams to

> And if you’re trying to skirt Conway, having multiple teams sharing a single deployable, you’re gonna have a bad time. Because good luck getting all teams to agree to drop everything and upgrade next sprint. this is why I'm not on team monorepo. Let other teams vendor their dependencies and upgrade on their own time. Just don't go trying to release N versions. Measure who is on an old version and work with them to update. But again, this slow team allows the other N-1 teams to adopt the new version and provide value to the org. for those of you who are pro monorepo and have worked in one with dozens of teams in different orgs who have competing priorities and can't upgrade a dependency in lock-step, how have you solved this?

frizlab 2y ago
Wouldn’t subtrees fix this instead of a mono-repo? Or even (gasp) submodules?
- dallasg3 2y ago
  I was looking into Paket for this on .NET. https://github.com/fsprojects/Paket https://github.com/fsprojects/Paket
- osigurdson 2y ago
  You mentioned sub modules - you are now on call until someone else mentions them again.
  - frizlab 2y ago
    I’m fine with that :)
mgaunard 2y ago
1. ensure you have continuous integration against both stable and latest versions of everything, with the stable set of all transitive dependencies defined on a per-project basis, and what gets used for releases. 2. people are expected to fix the latest build whenever they have spare cycles. The incentive is that it is part of the pipeline for code reviews and can only be bypassed by the project owner. This means you'll need to support both stable and latest concurrently (bumping stable is also an option to simplify the requirement). 3. if you added conditional support for old stable/new latest and latest was eventually made stable, you can refactor that code.
osigurdson 2y ago
Does monorepo confer that all projects use the same dependencies? Binary dependencies seem orthogonal to how source code is managed.
- adastra22 2y ago
  Usually, yes. Monorepo means all dependencies are checked into the same repo. Even external dependencies (when source available) are checked in.
  - osigurdson 2y ago
    Usually we are using package managers and just referencing packages. However, even in the hypothetical where I am downloading binaries and checking them in, I still don't see the relationship to the monorepo. I can have a monorepo with 100 folders representing 100 programs, each of these can have completely separate dependencies, languages, etc. Dependency versions matter when they are all part of the same program or library. Then you have the diamond dependency issue and related problems. However, none of this is related maintaining code in a monorepo. One program can be maintain in 10 different repos (impractical but possible) and still have the diamond dependency issue.
- hinkley 2y ago
  I’ve done monorepo, separate compilation units before. It has its own set of issues but it cuts down on circular dependencies and makes more sense than having sixty repositories checked out. Those are hell.

frizlab 2y ago

Wouldn’t subtrees fix this instead of a mono-repo? Or even (gasp) submodules?

dallasg3 2y ago
I was looking into Paket for this on .NET. https://github.com/fsprojects/Paket https://github.com/fsprojects/Paket
osigurdson 2y ago
You mentioned sub modules - you are now on call until someone else mentions them again.
- frizlab 2y ago
  I’m fine with that :)

mgaunard 2y ago

1. ensure you have continuous integration against both stable and latest versions of everything, with the stable set of all transitive dependencies defined on a per-project basis, and what gets used for releases. 2. people are expected to fix the latest build whenever they have spare cycles. The incentive is that it is part of the pipeline for code reviews and can only be bypassed by the project owner. This means you'll need to support both stable and latest concurrently (bumping stable is also an option to simplify the requirement). 3. if you added conditional support for old stable/new latest and latest was eventually made stable, you can refactor that code.

osigurdson 2y ago

Does monorepo confer that all projects use the same dependencies? Binary dependencies seem orthogonal to how source code is managed.

adastra22 2y ago
Usually, yes. Monorepo means all dependencies are checked into the same repo. Even external dependencies (when source available) are checked in.
- osigurdson 2y ago
  Usually we are using package managers and just referencing packages. However, even in the hypothetical where I am downloading binaries and checking them in, I still don't see the relationship to the monorepo. I can have a monorepo with 100 folders representing 100 programs, each of these can have completely separate dependencies, languages, etc. Dependency versions matter when they are all part of the same program or library. Then you have the diamond dependency issue and related problems. However, none of this is related maintaining code in a monorepo. One program can be maintain in 10 different repos (impractical but possible) and still have the diamond dependency issue.
hinkley 2y ago
I’ve done monorepo, separate compilation units before. It has its own set of issues but it cuts down on circular dependencies and makes more sense than having sixty repositories checked out. Those are hell.