<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi folks, Neither mono- nor multirepo organization is inherently better or worse. We should look at the practical issues. From a developers perspective, some would be: <ol> <li>Do we want different versions of the source code checked out at the same time? In the end, this comes down to whether different components have their own release cycle, for example, we might develop the next version of the work item storage service, but the UI still runs against a previous version of the API. Our advertised approach is to always have master in production. Since we have different people working on the back end and the UI, I don't expect us to be able to make changes to the back end and front end in the same pull request. However, we may have an integration branch where we collect the related changes and then promote them to master atomically. If we have multiple repositories, we will have to prevent breakage some other way: for example with a "no breaking changes" policy (using a deprecation window) or by good old coordination between contributors.</li> <li>Tool support I use VSCode to program in go (in my opinion, the code editor that sucks the least ;-)). However, if I checkout both almighty-core and almighty-ui and then open the parent folder in VSCode, I can't use the git tooling in VSCode anymore. So for me, monorepo would work better.</li> <li>The downside of monorepo is that you can't ever check out less than the whole repo. But aside from some wasted disk space, what's the problem with that? </li> </ol> Note that this is purely a git issue, if we had a svn repo, we would naturally have a single repo with multiple projects (folders) in it. My conclusion is that I see a monorepo approach as slightly more convenient. However, I don't think this is a game changes either way. /Thomas </body> </html>