Hacker News Reader

Comment by TickleSteve | Hacker News Reader

This is obvious to me (a monorepo advocate) but most people these days tend to organise their repos based on module/implementation lines rather than on product boundaries.

My motto is: "What you release together, you should version-control together".

View on HN

I've learnt that for "What you release together, you should version-control together", the phrase "released together" needs to be defined as "what gets globally updated at once". If you provide anything for customers to implement, you cannot update those globally at once (because you need the customer to update), and should think about using a multi-repo set-up.

My experience is that testing the interactions of historic versions of different components in a mono-repo against each other is difficult. With a multi-repo set-up, one can checkout to whatever historic version one needs to test. That makes it trivially easy to set-up testing that allows one to test historic versions of components against each.

I'm a multirepo advocate, but I suggest splits similarly.

Maybe it's my old-timey way of releasing software, but because I do releases as RPMs, it bothers me less if you do things like have your base library, your backend services, and your frontend in the same repo. If they need to be able to be deployed independently, I just split them up as subpackages.

I guess most language package managers don't really have such a concept, so people are optimizing for that...

I like having one repo for the project ("What you release together") that tracks subprojects as submodules.

Reply on news.ycombinator.com