| Re: [rdf4j-dev] what major/breaking changes do we want? and when do we want them? |
|
Hi Jeen,
removal of the deprecated items is already a great feature :-)
I'm currently working on / thinking about minor things (console stuff, waiting for ES/Lucene CQ's to be approved for upgrading dependencies, maybe a subpackage for EU and/or Schema.org vocabularies...)
One "major" feature would be to be able to compile RDF4J on OpenJDK 11 LTS (but stick with JDK 8 as a minimum) Which could be as trivial as changing mvn poms to include some java.ee dependencies removed from JDK, or more complicated if modules are to be used... I don't have much coding experience in JDK 9 and above.
What about upgrading the tests frameworks ? IIRC they are mainly based on JUnit4 / Mockito 1.
Best regards
Bart From: rdf4j-dev-bounces@xxxxxxxxxxx <rdf4j-dev-bounces@xxxxxxxxxxx> on behalf of Jeen Broekstra <jeen.broekstra@xxxxxxxxx>
Sent: Monday, December 17, 2018 4:58:02 AM To: rdf4j developer discussions Subject: [rdf4j-dev] what major/breaking changes do we want? and when do we want them? Folks,
The milestone for the next major release, 3.0, is undated, and has no real focus at the moment. As you can see here:
There isn't a lot of exciting new stuff planned for RDF4J 3.0 - it's mostly just about removing deprecated stuff and doing some cleanup.
So the question is: can we think of any major things that we'd like to include in RDF4J in the near future, stuff that we should
start thinking about and putting tickets into the 3.0 milestone for?
And when do we want to start thinking about doing a major release? Is first thing after minor release 2.5 a good idea? Or should we wait until we actually have something major and urgent ready to put in there?
Note: I'm perfectly fine with doing a major release even if most of what we do is non-exciting cleanup stuff. But it'd be a shame if we do a major release, and then two weeks after we figure out we want to do this other non-backward-compatible thing.
Cheers,
Jeen
|