[tored]

How would you handle versioning in a monorepo? Just a new directory for major versions?

If we have multiple teams you can’t really refactor other teams code and sometimes you need to do breaking changes thus I imagine that some versioning must exist.

[tmerr]

That's a great question. What I've seen is versioning de emphasized. Good unit & integration test coverage to prevent refactor breakage. And when you make a large change that affects consumers of your library, you find a way to do it incrementally. E.g. instead of changing a function's parameters, you can create a second function, migrate everyone over, then delete the old one. And of course, you would not ordinarily modify another teams code without first getting their LGTM.

[jvolkman]

A big part is engineering culture. At Google having multiple versions of a thing is an exceptional situation. But it's also acceptable (to an extent) to refactor other peoples' code and send them PRs. If you need to make a significant change, you do it in phases that allow you to maintain compatibility until you or someone else is able to migrate usages to the new ways.