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

[Peter Ansell <ansell.peter@xxxxxxxxx>]

Modules were added in Java-9, but the first of the new
"Long-Term-Support" releases that the OpenJDK community and others are
going to be supporting is likely to be Java-11.

Modules let you specify for users of Java-9+ which classes they are
not allowed to access if they are following the module rules and the
access rules are enforced unless the user switches them off (which may
still happen but they can't blame us as we tried to tell them not to
touch particular classes).

The biggest issue with Modules which may require a Major Version is
that they strictly enforce package-to-module uniqueness. Ie, you can't
define classes for a single package in more than one module. We have
had some small issues with that in the past, but not sure if they
still exist. If they exist, a Major Version would be the time to fix
them.

Once the build system is working with Java-11 (mostly maven plugin and
dependency updates on my projects so far), it may be easier to work on
adding Modules.

Peter

On Thu, 27 Dec 2018 at 08:46, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:
>
> 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
>
> _______________________________________________
> 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