Thanks both,
I share the desire to have a 4.3 release out soon. The way I see it, there are currently a few potential roadblocks:
First, the Jakarta EE upgrade. There are a number of open pull requests related to this work:
It is currently not clear to me what the state of the upgrade work is, and which of these PRs are critical for it. Erik, do you think you could provide a summary on how this all ties together and if possible give us a judgment on which are necessary for a 4.3 release, and which can be postponed or perhaps even closed (if no longer relevant)? If there's specific things you think someone else could help out with, by all means shout out.
The second potential roadblock is related to the config vocabulary change. Havard identified that although at a code level the change is backward compatible, it will catch users out if they access the config models directly (if they query using old vocabulary, their code will stop working correctly). He's pushed up a draft attempt to mitigate this (see
https://github.com/eclipse/rdf4j/pull/4533 ) and we're having discussions about the best way forward. I wouldn't mind some additional opinions here either.
Third: the Solr/Lucene/Elasticsearch upgrade work. See
https://github.com/eclipse/rdf4j/issues/3396 . Bart has been pursuing this, and I think he managed to get the legal side of it all sorted, but I'm not sure where we're sitting with the actual upgrade work. This one we may consider non-critical I think, and postpone if necessary.
Other than that, there are currently 28 open issues planned against the 4.3 milestone:
https://github.com/eclipse/rdf4j/milestone/89. I've weeded a few out that I consider non-critical, but would appreciate other eyes on this as well.
On a personal note: I am leaving for a holiday on the 18th of May, and will be away for 4 weeks. That means that if we want to do a release in 2 or 3 weeks time, either Havard or someone else will need to manage it: I won't be available.
Jeen
On Fri, 5 May 2023, at 19:01, Erik Godding Boye wrote:
Hi,
I second Andreas' wish! We want to move forward with our Spring and Spring Boot upgrades in projects with dependencies to rdf4j libraries, and that is not possible without the unreleased changes regarding javax/jakarta. Please let me know if I can assist in any way! I have plans to move forward with the proposed Java/Jakarta EE upgrades, but I seem to be blocked by a few things right now and will need more time to find a good solution.....
Regards,
Erik
Hi all, Jeen
I'd like to come back to the release planning once more,
specifically 4.3.0
We are approaching the final phase of our product release and would
require a proper (final) release of RDF4J, i.e. 4.3.0. Note that we
are currently using 4.3.0-M1 and for our final release want to
switch to 4.3.0
Would it be possible to aim for the 4.3.0 release within the next
two weeks from now?
Thanks,
Andreas
Am 23.04.2023 um 04:09 schrieb Jeen
Broekstra:
Sorry Matthew, 4.2.4 is already out the door - but there's
always a next release :)
Jeen
On Sat, 22 Apr 2023, at 23:48, Matthew Nguyen via rdf4j-dev
wrote:
Hi Jeen, I expect to submit a patch to the
activetransactionregistry (to make it pluggable) over the
next couple of days. Wouldn't complain if 4.2.4 stalled til
next weekend :-)
Thanks all - I didn't get around to doing any
releases last weekend, in the end, however I've
got some time today and tomorrow. I'm taking a
quick look at
https://github.com/eclipse/rdf4j/issues/4512,
after that I'll prep the 4.2.4 release. Not yet
sure I can get around to a second milestone this
weekend - we'll see how it goes.
Jeen
On Wed, 12 Apr 2023, at 07:58, Bart Hanssens
(BOSA) via rdf4j-dev wrote:
Hi,
I’m hoping to get the
(somewhat) newer versions of ES / Solr /
Lucene approved for 4.3.0
(still a few small CQs that
need IPR-approval from Eclipse…
I’ll have to send a few
gentle reminders since the tickets have
been entered quite some weeks ago)
Though not a blocker IMHO…
Best regards
Bart
Hi
Jeen,
thanks
for the initiative.
I'd
like to comment from our perspective
on 4.3.0:
we
are currently using the 4.3.0 M1 build
(which for us allowed to do the
Jakarta EE migration by getting rid of
JAXB in the core modules). For our
final product release we would like to
ship a proper RDF4J release, i.e.
4.3.0. From the timeline it would be
really great to have the 4.3.0 out
within the next 4 weeks, which should
be in line with what you are stating.
One
further remark: the current 4.3
snapshot contains the changes to the
repository configuration schema /
vocabulary. We can offer to test this
in the wild (specifically w.r.t
backwards compatibility) when there is
another M2 milestone. Do you think it
makes sense to have another M2 build
for this?
Regarding
4.2.4: no strong opinion. If there are
fixes, better to roll them out earlier
than later :)
I
was considering doing a 4.2.4
patch release next week as
there's several bug fixes
available (see https://github.com/orgs/eclipse/projects/36/views/4 ). There's also a couple of open
bug reports, some of which are
in progress, but they seem to
have stalled a bit (partly due
to myself not having a lot of
spare time these days).
I'd
also like to propose that we
start thinking about a release
for 4.3.0. Ideally I'd like us
to get to a 4.3 final release
quite soon, so that afterwards
we can merge the 5.0 branch into
develop, and give its
development more priority.
There's
still a lot of open issues
planned against 4.3 but I want
to do some culling in that, move
them back to 5.0 or unplanned
until we can get around to them.
There's some things I'd
_definitely_ like to see
included though. For me, the
main themes of 4.3.0 are:
- prep
of our project to migrate fully
to Jakarta EE (all the work Erik
GB has been doing)
- migration
to tag-based config vocabulary
- various
SHACL features and improvements
Thoughts?
Questions? Protests?
_______________________________________________
rdf4j-dev mailing list
_______________________________________________
rdf4j-dev mailing list
_______________________________________________
rdf4j-dev mailing list
_______________________________________________
rdf4j-dev mailing list
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
_______________________________________________
rdf4j-dev mailing list