| I've merged Bart's branch and created a PR with Erik's dash fix :)
Once that is merged I'm going to publish a new milestone build. If everything looks good then I'll create a release tomorrow.
Cheers, Håvard On 17 May 2023, at 21:37, Erik Godding Boye <egboye@xxxxxxxxx> wrote:
Bart,
Wouldn’t force merging the PR create issues for future PRs? That said, I am am keen to get the upgrade merged, as it seems like the main blocker for javax -> jakarta migration at present.
I am planning to review the status on that migration this week (tomorrow probably), ref the question from Jeen. Sorry for slow response time….
Regards, Erik
Hi, in terms of the ES/Solr upgrade, can I just force-merge the PR, or is there something else to do in order to ignore the
approved-but-license-not-flagged-correctly ES dependency ? Best regards Bart
Hi Håvard,
can you give an update to your current plans of converging to the 4.3.0 release? Maybe also another comment from others?
I have seen that the backwards compatibility change for the CONFIG repository has been merged. How about other relevant changes?
For our product we are approaching the final development phase and we'll go to QA mode shortly. Ideally we would have the 4.3.0 ready before going to QA.
Hi everyone,
On my side I have the PR to fix the backwards compatibility of the new CONFIG vocabulary together with a PR for an adaption of the ShaclSail that supports SHACL validation of data in other sails without having to move the data into a ShaclSail.
I have a goal of getting at least another milestone build out in the next week, and preferably a release soon after that.
Cheers,
fwiw, the Solr/Lucene/ES is "done" as far as I'm concerned (have to squash'n'merge it).
There is only 1 license warning on ES left, but that component was actually approved
(the dash-license tool still fails due to a manual error in the EMO approval process,
not sure if EMO will eventually fix the label or not)
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.
On Fri, 5 May 2023, at 19:01, Erik Godding Boye wrote:
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.....
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?
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 :)
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.
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
_______________________________________________
_______________________________________________
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@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev
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@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev
|
