I think the above is what many other people are suggesting already. Unless I've misinterpreted the requests. With that in mind I suggested this < http://tinyurl.com/p2nt3co> as a library structure (suggestion #2). Adding here the second option " Second
Le 03/02/15 01:16, Rene Rivera a écrit : option is to have each library have to explicit sublibs/parts. "core" and "full". Structure would be: * libs/<lib>/core/(build, doc, include, meta, test) * libs/<lib>/full/(build, doc, include, meta, test) Note, both core and full would be in the same git repo to make life easier for library authors and users that visit a library git repo on github. As it's only one place for everything for that one library. As a user, release manager, testing manager, and library author this would be easy to understand and manage than the current "some random set of libraries have core or not and in different places". " IMO, this is a minor variant of what we already have. Consider libs/<lib> to play the role of libs/<lib>/full. Your structure is more explicit, but I don't think we need to go so far as the submodule information is on the meta/libraries.json file. This doesn't mean that a library can not do that. I find very useful to split a library into submodules. * It helps to limit the dependencies as more fine grained, * it makes easier to move a submodule from one github repository to another as the structure of a submodule is the same as the structure of a library (a submodule it self). This could be useful if we want to transfer the maintenance of the submodule. Robert, your bridge proposal could just consist in creating libs/serialization/bridge/(build, doc, include, meta, test) and adding the submodule on the libs/serialization/meta/libraries.json file. Best, Vicente