With the maven-release-plugin version that has just been released releasing individual modules in a large git repository works nicely, thanks Benson for pointing me to this!
Still a self-service multi-git solution would be nice to have, but for me it definitively lost some of its urgency. Cheers, Reto On Mon, Sep 22, 2014 at 8:36 AM, Paul Davis <[email protected]> wrote: > Forgot to reply to this earlier. From the CouchDB side of things, even > though we have many repositories, the combination of all those > repositories will constitute a single source release. Our repository > breakdown is mostly driven by how Erlang-the-language mandates a flat > namespace coupled with Erlang-the-ecosystem which has developed > tooling that expects individual repositories. > > Paul > > On Sun, Sep 21, 2014 at 10:33 PM, David Nalley <[email protected]> wrote: > > On Sun, Sep 21, 2014 at 12:26 PM, Reto Gmür <[email protected]> wrote: > >> Hi Brian, David, all, > >> > >> Thanks for your feedback - and sorry for my late reply. > >> > >> I did some more playing around with the mvn:release plugins and > >> unfortunately found no way to use it for individually versioned projects > >> sharing a singe git repo. The maven git flow plugin also assumes one > version > >> per repository. > >> > >> Regarding the management of the repos: We do not plan to mandate the > use of > >> any tool. One of the advanatges of 1-repo per module is that people only > >> need to check out and get into the subprojects they are actually > interested > >> in. Reactor projects will use git submodules to integrate the modules, > so > >> one can get all the modules by recursively updating the submodules of > the > >> root-reactor. > >> > >> In the case we want to draft a change that spans over multiple modules > we > >> would have to individually branch those projects and branch the reactor > or > >> provide a temporary reactor that contains only the branched projects. > The > >> temporary reactor approach is possible as the module depend on the > released > >> version of other modules by default, so the modules would depend on a > >> SNAPSHOT version only where this is also branched. > >> > >> As for the release process: A goal of the new approach is to make > releasing > >> much easier ans thus much more frequent. So often we will be releasing > just > >> a single module. When releasing multiple modules we will generate > several > >> artifacts and call for a common vote. A single vote is necessary if the > >> modules are interdependent, as otherwise the votes would have to be held > >> sequentially following the dependency chain. > >> > >> Even if Infra is *very* responsive for 200 repos having a self-service > >> system seems to be more convenient. Allura looks good, gitlab might be > a bit > >> easier as it is focused on git. > >> > > > > I don't disagree that having a self-service system would be > > convenient; it's come up in conversation several times in the past few > > months. However, this isn't currently a priority for infra. For the > > moment, projects have to keep their source code in an infra-maintained > > repository. > > > > --David >
