Re: [rdf4j-dev] what major/breaking changes do we want? and when do we w

[Jeen Broekstra <jeen.broekstra@xxxxxxxxx>]

Yeah I agree, that's definitely something we want to nail down. I'm not really sure about the best way to do this though. I haven't really looked at java 11 yet, so not really familiar with its module concept. 

Other ways would be to fully isolate public APIs in their own maven modules, and reorganise the compliance tests to make it more explicit which tests cover expected behaviour for (both our own and third party) implementations. Also better organisation of the javadoc could help. This is all less formal but perhaps a good first step.

Cheers,

Jeen

On Mon, 24 Dec. 2018, 16:52 Peter Ansell <ansell.peter@xxxxxxxxx wrote:

On Mon, 17 Dec 2018 at 14:58, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:
>
>
> 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:
>
>  https://github.com/eclipse/rdf4j/milestone/17
>
> 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.

A declaration of what modules and packages are considered as part of
the "Public API" for SemVer purposes would be useful for a major
version bump (even if it isn't done on the 2.x branch).

https://github.com/eclipse/rdf4j/issues/619

Formalising that using named modules would be the cleanest way in the
long term. Modules are still Java-8 compatible although you can't
compile 'module.java' using Java-8 so all developers would need to
switch to Java-11 for RDF4J internal development once the build bugs
are fixed.

https://github.com/eclipse/rdf4j/issues/1148

Cheers,

Peter
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev