Re: [rdf4j-dev] Split RDF4J Project

[James Leigh <james.leigh@xxxxxxxxxxxx>]

On Wed, 2017-09-13 at 09:40 +1000, Peter Ansell wrote:
> On 31 August 2017 at 05:18, James Leigh <james.leigh@xxxxxxxxxxxx>
> wrote:
> > and staggered release dates. Similar to the way HttpComponents has
> > HttpClient and HttpCore. The URLs would be:
> > 
> > https://github.com/eclipse/rdf4j
> > https://github.com/eclipse/rdf4j-storage
> > https://github.com/eclipse/rdf4j-tools
> > https://github.com/eclipse/rdf4j-testsuite
> > https://github.com/eclipse/rdf4j-doc
> Managing each of the components separately based on function is great
> for development (not so great for testing in the current state given
> the general lack of unit tests and reliance on the testsuite modules
> for coverage, but that can be improved).
> 
> My only objection is to staggered release dates, which would imply
> that the most current version for each component won't be the same,
> and a user may not be able to update to the latest client code until
> storage has been released, for instance, or hypothetically there may
> be more patch releases for the client code than the storage, leading
> the version numbers being out of sync.
> 
> If releases are staggered, there also needs to be discussion about
> where the rdf4j-bom (containing the latest versions) would be
> located.
> It can't be located in rdf4j (client module) anymore, as client would
> then need to be released again for each of the staggered release
> dates
> for storage and tools come up, which would imply that the storage and
> tools release cycles would still be affecting rdf4j (client module).
> rdf4j-bom would need its own repository, possibly co-located with the
> parent pom (or have the parent pom in a separate repository).
> 
> I still see it as essential that there is a single version number
> common across the entire RDF4J module set for the most current
> version, leading to non-staggered release dates as a conclusion. The
> HttpClient and HttpCore model is not a good model for RDF4J IMO, as
> even it with its small number of modules (compared to RDF4J) has
> given
> me issues in deciding whether a given project has
> compatible/up-to-date releases for each.


I plan on keeping the version numbers consistent across rdf4j projects.
When I said staggered, I expect that a full release of rdf4j might take
about a week to get out, as opposed to everything out on the same day.
There might be a week before rdf4j-bom is released to point at the
newest rdf4j-client version. However, that could be advantageous as it
would allow more people (who are keen to get a hold of the latest
rdf4j-client) a chance to further verify the release before rdf4j-bom
is released to a wider audience.

btw, I have started to create the branches. You can take a look at the
split in the links below:

https://github.com/jamesrdf/rdf4j/tree/issues/%23915-split-project
https://github.com/jamesrdf/rdf4j-storage/tree/issues/%23915-split-proj
ect
https://github.com/jamesrdf/rdf4j-tools/tree/issues/%23915-split-projec
t
https://github.com/jamesrdf/rdf4j-testsuite/tree/issues/%23915-split-pr
oject

Regards,
James