Thank you for taking the time for a thoughtful response, it's good to get some context about why things are as they are.
Previously I have worked in large organisations were most projects were using a single repo for a given project, with multiple projects spread across many departments. So a typical project might be 20-30 developers working on a given repo over a number of years, normally grouped into traditional tiers of client, server, and persistence, shared comms, utils, and monitoring. So a given release is the total sums of those parts, and probably why traditionally they have been kept together in a single repo (and for simplicity), since a VCS label represents a known state across all inter-dependencies. Some companies handled this better than others, with well documented APIs between dependencies, but not many. And less so with agile polyglot full-stack developers hacking away at all tiers :) So taking into account my new information, each one of those parts of the larger project would now be a single repo+module in Go. I'm fine with that, now I know it's intentional. But then how would I group these into a whole? I don't see any build tools like ant/maven/graddle that can handle Go. Would it be reasonable to have another separate repo, that purely holds a go.mod file which lists all the different module versions of it's constituents? and in doing so represents a given release. Or how do others manage this? Peter -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
