Monorepo vs polyrepo

[hannobraun]

I have an idea, and I'm wondering what people think about it. I'm interested in @hendrikmaus's opinion, specifically.

I just did a release of threemf, and while it was not a big deal, there was more friction than I would have liked. Figuring out what I have to set up to get automatic merges to work took alone took a few minutes, interrupting the work I was actually going to do multiple times.

As I said, not a big deal. But it's a sign of what's to come, if start to move crates out of the repository, as we talked about in #104. That's why I like the monorepo approach. Set things up once, no needless friction from then on. However, I said before that there's a trade-off, as monorepos start becoming cumbersome, once you have crates with different release cycles in them. I still think this is true.

So here's my idea: Keep everything Fornjot-related in a single monorepo, and force all crates to have the same release lifecycle. Do one release of all Fornjot crates at the same time. That could mean we publish version 0.{x+1}.0 (or later {x+1}.0.0) of a crate, even though it had no breaking changes. Or in the extreme case, no changes at all.

The disadvantage is potential churn in the ecosystem. You might have multiple versions of the same dependency in your dependency graph, which could even result in build errors in your own code, even though all dependencies could use the same version without changes required. (Although, if no changes are required, upgrading those dependencies is going to be trivial.)

However, besides us getting to have a monorepo, there is one other big advantage: It's simple. If you use multiple Fornjot crates, you always know that you need all of them at the same version, and that's it. No wondering about which fj-kernel version works with which fj-interop version works with which fj-graphics version. You always just know, at a single glance.

I think this is a big advantage. It might be the right trade-off, even if we take the monorepo question out of the equation.

I'd love to hear what people think! Right now I'm leaning towards just implementing that scheme, then re-evaluate later, if it causes problems.

[hendrikmaus]

Keep everything Fornjot-related in a single monorepo, and force all crates to have the same release lifecycle. (...) advantage: It's simple.

I couldn't agree more. If you go monorepo, releasing everything at the same time with the same version takes the pain away.

[hendrikmaus]

I agree. I would also conclude that having the peace of mind to simply use a single version for every fornjot component is a huge win.

[zopieux]

I'm not very knowledgeable about Rust tooling and development guidelines, but I'd add a possibly naive point in favor of monorepo: Rust has increasingly good support for workspaces which basically solves the "single VCS but multiple components" aspect of things. In fact, it seems like it's what all big crate ecosystems out there are transitioning to.

[hannobraun]

Thank you for the feedback @zopieux! I completely agree that Rust and Cargo should not cause any problems in regards to a monorepo approach. I mean, they haven't so far 😄

[seanjensengrey]

A single gitrepo for the project and its immediate libs has additional benefits

• single checkout without using submodules
• this is in turn makes it easier for new contributors
• refactoring across libs is much simpler
• don't have to commit across repos
• if it moves together, it should be in the same repo
• easier to break it out then pull it back in

I really like all the crates having the same version number. In Java land I would often get version number blindness, knowing that sets of crates are compatible in this way reduces cognitive load.

[hannobraun]

Thank you for the feedback, @seanjensengrey! I'm also very happy with this approach so far.