On 27/05/2019 16:12, Marco Neumann wrote:
can you let us know what that entails on your end? is it primarily a matter
of managing branches on github?
Bandwidth! Better to do Europe-morning than later in the day.
We release from the master branch and, with the Jenkins jobs, should
always be green.
The process is described here:
https://cwiki.apache.org/confluence/display/JENA/Release+Process
Using the maven release plugin, with customization by the Apache parent
POM means the code part of release is running
mvn release:prepare
mvn release:perform
then
prepare dist area (scripted)
then local check
then VOTE email.
During or after the VOTE,
prepare javadoc
update download page.
After VOTE:
Push maven artifacts out
Move dist area to /dist/jena
Update website
and update JIRA.
Some of the steps take a while, so going off to do some reading etc
overlaps.
Andy
On Mon, May 27, 2019 at 3:42 PM Andy Seaborne <a...@apache.org> wrote:
OK then - I'll start on 3.12.0.
On 20/05/2019 21:46, ajs6f wrote:
I'm fairly open this next week and the first week of June.
ajs6f
On May 19, 2019, at 8:55 AM, Andy Seaborne <a...@apache.org> wrote:
Greg's GeoSPARQL implementation is ready. It's on a branch in git and
ready to merge - legal NOTICES are done as is disabling tests under
Java11
(boo, hiss) because of the test failures due to tiny double
precision/string representation changes Java8 -> Java11.
So we can do Jena 3.12.0 with GeoSPARQL as discussed on the "Towards
Jena
3.11.0" thread.
This message is to ask about timing - when might people have a chance to
vote on a release? what timing works for you? I can RM this month.
Andy
PS I have a couple of things "in progress" : TDB2 migrated to the
jena-dboe-storage framework and redoing Fuseki request dispatch but I'm
holding back - this release is about GeoSPARQL.
