Hi Jeen,
Done
😊
I’ve removed all the images from hub.docker.com (they can be added again, if needed),
and added the new 3.1.4, -latest (which points to as 3.1.4) and 3.2.0-M2 milestone releases,
both for x86-64 and arm64v8.
They are still based on JDK8, by the way.
Switching to JDK11 is easy, but that would increase the image size.
Best regards,
Bart
From: rdf4j-dev-bounces@xxxxxxxxxxx <rdf4j-dev-bounces@xxxxxxxxxxx>
On Behalf Of Jeen Broekstra
Sent: zaterdag 25 april 2020 9:21
To: rdf4j developer discussions <rdf4j-dev@xxxxxxxxxxx>
Subject: Re: [rdf4j-dev] Fixing existing release distributions due to GH-1098
Thanks Bart, I had completely overlooked that we'd need to do this for the docker images as well.
I've pushed new releases and taken old release distributions offline where necessary. Could you give me a ping when you've managed to do the same for the docker images? Btw I wouldn't worry about 2.5 or older, just remove those builds.
Nice. I’ll update the docker images as well (and remove some older versions)
Note to self: test if the docker images can automatically be built and uploaded (e.g. using Docker actions)
Best regards
Bart
That sucks. Nice of you to fix it though, even so far back as the 2.5 release :)
As you may have seen, we have a problem with our release distribution, which includes a dependency on an org.json library that is not approved for reuse by EF (see
https://github.com/eclipse/rdf4j/issues/1098). The reason, by the way, is that its license is not approved: it includes an extra "use only for good not evil" clause which is not considered
open-source compatible.
I am not sure why we never detected this before to be honest, as this dependency has been lurking there since we first moved to Eclipse.
Fortunately, we really don't need this library, as we have Jackson, which is a superior choice for creating JSON artifacts anyway. The org.json library is only used in the RDF4J
Workbench, in two places. I've put up a pull request which removes the old dependency and replaces its use with equivalent Jackson code. See
https://github.com/eclipse/rdf4j/pull/2127 .
However, because we have no approval to use/distribute this library, we will need to retroactively fix the distributions of previous releases (only SDK and onejar downloads fortunately,
not the artifacts on maven central).
How I plan to fix this is as follows:
1. I will create a new 3.1.4 patch release that includes this fix (and one or two other bug fixes). I will completely remove older 3.1.x releases from the download servers.
2. I will also create a new 3.2.0 Milestone build (milestone 2) that includes this fix. I will remove milestone 1 from the download servers.
3. For 3.0, I will generate a new release 3.0.5 with this change as the only fix. This will not be advertised but will become the linked download under the "older releases" heading
on the website. Older 3.0.x releases will be removed from the download servers.
4. For 2.5, I will not generate a new release (as the rdf4j-storage and rdf4j-tools repos are now read-only, so I can't push tags), but what I will do is locally fix on the 2.5.5
tag, generate a new release SDK and zip, and just replace the existing downloads on the server. Older 2.5.x release will be removed.
For older releases than that I will just remove the download, and not bother with respinning it.
I'm not particularly happy about having to remove release artifacts, but in practice I think this will cause very little inconvenience - there are few good reasons why someone who
downloads the SDK or onejar would need an ancient version. And if someone complains and does have a valid reason for needing it, we can always look at it on a case by case basis.
_______________________________________________
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
|
