Hey All Following up on the recent discussion points Andy raised around module structuring as the project expands its scope and modules do we want to think about reorganising our repository and how we do releases?
For discussion lets consider splitting the current modules up into several sub-projects like so: * commons - jena-iri and Claude's proposed jena-commons module * core - jena-core, jena-arq, jena-tdb, jena-security * search - jena-text, jena-spatial * fuseki - jena-fuseki * jdbc - All JDBC modules * sdb - jena-sdb * client - Stephen's experimental jena-client module * hadoop - The jena-hadoop-rdf modules (This is just an illustration, what goes in which sub-project can be decided later, this is intended to stimulate discussion rather than to be a concrete proposal). So rather than having a flat trunk structure with each module in the root we would have a structure where each sub-project has a directory in trunk with its modules located under it. In this structure jena-parent then lives in the top level directory. With such a structure we could then consider having different release cadences for different sub-projects. So when we do a new core release we would not necessarily have to release everything else at the same time (though in most cases I suspect we would want to), however if a sub-project wants to make an interim release in the meantime there would be nothing to stop this happening e.g. making a critical bug fix, tracking a sub-project specific dependency release Obviously doing this kind of restructuring would be really painful with SVN so might I suggest that any such change should happen in conjunction with a move to Git? The other alternative to such a trunk structure is to have each sub-project live in its own Git repository which does appear to be something that Infra supports - the list of repos at https://git-wip-us.apache.org/repos/asf shows multiple repos for several projects (Accumulo, ActiveMQ, Ant to name just three near the top of the list) - so we could certainly go down that route if we wished? In that scenario then jena-parent would need to live in its own repository as well (probably the main jena repo would contain just jena-parent and pointers to the other repos). However this approach would complicate releases somewhat since you likely need to have multiple release votes and release artifacts since cutting a release might mean releasing from multiple releases and each would need reproducible sources. Thoughts? Rob
