If you're interested in reading about how Google uses their monorepo, they have a paper you can read through: https://research.google.com/pubs/pub45424.html
It's not clear to me reading the paper if they do this for all of their projects(including public repos on github) or just in-house code; it sounds like the latter. It's not something that would be practical for most projects. -Robert Middleton On Wed, Jan 24, 2018 at 7:45 PM, Matt Sicker <boa...@gmail.com> wrote: > I'm going to sum up my view here: if we split up repos to include plugins > that depend on log4j-core, then we first need to define and release a > stable plugin API. If we can't guarantee BC for plugins, then there's no > realistic way to both split out additional plugins and have them be > officially endorsed plugins. If said plugins were completely outside Apache > (e.g., personal GitHub pages), then it wouldn't be as strict. > > Also, I find it hard to believe that Google really uses a monorepo anymore. > Such an idea wouldn't work too well with software that isn't continuously > released. > > I suppose that's an alternative: I'd be open to splitting up repos however > desired if releases were continually published to avoid version number > synchronisation efforts, but I'm not so sure how well that meshes with the > Apache Way for releasing software.
