Re: [rdf4j-dev] Split RDF4J Project

[Peter Ansell <ansell.peter@xxxxxxxxx>]

On 13 September 2017 at 23:02, James Leigh <james.leigh@xxxxxxxxxxxx> wrote:
> 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.

That sounds great!

> 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

Thanks, I looked a little but haven't verified anything using maven. I
am not going to be able to review it for a few weeks due to personal
events but it definitely looks like a useful strategy.

Cheers,

Peter