Re: [VOTE] Apache Jena 3.11.0 RC1
+1 Andy On 19/04/2019 20:39, Andy Seaborne wrote: Hi, Here is a vote on a release of Apache Jena 3.11.0. This is the first proposed release candidate. The deadline for the vote is Tuesday, 23rd April, 2019 at 17:00 UTC Release changes: 37 JIRA: https://s.apache.org/jena-3.11.0-jira == Changes of note: JENA-1691 : Metric services for Fuseki Sean Ryan JENA-1664, JENA-1665, JENA-1673 SDB improvements including performance of OPTIONAL, MINUS Graham Triggs JENA-1686 Set Dyadic#getL() and Dyadic#getR() return type to Graph Jan Martin Keil JENA-1674 : Fix mishandling negative xsd:floats in TDB2 JENA-1644 : ParameterizedSparqlString Empty List fix Greg Albiston Improvements to TDB1 and TDB2 handling bad I/O during transaction commit. == Updates commons compress 1.17 -> 1.18 libthrift 0.10.0 -> 0.12.0 jsonld-java 0.12.1 -> 0.12.3 Additionally, control the version of Jackson: 2.9.8 due to CVE's fileupload 1.3.3 -> 1.4 slf4j -> 1.7.25 -> 1.7.26 (CVE upgrade) new: io.micrometer: 1.1.3 and recursive dependencies: org.hdrhistogram:HdrHistogram:jar:2.1.9 (BSD-2-Clause) org.latencyutils:LatencyUtils:jar:2.0.3 (BSD-2-Clause) Release Vote Everyone, not just committers, is invited to test and vote. Please download and test the proposed release. Staging repository: https://repository.apache.org/content/repositories/orgapachejena-1029 Proposed dist/ area: https://dist.apache.org/repos/dist/dev/jena/ Keys: https://svn.apache.org/repos/asf/jena/dist/KEYS Git commit (browser URL): https://github.com/apache/jena/commit/4b2f7f32c041 Git Commit Hash: 4b2f7f32c0410cca6636b58a89b51d5eb56f247e Git Commit Tag: jena-3.11.0 Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open until at least Tuesday, 23rd April, 2019 at 17:00 UTC If you expect to check the release but the time limit does not work for you, please email within the schedule above with an expected time and we can extend the vote period. Thanks, Andy Checking needed: + does everything work on Linux? + does everything work on MS Windows? + does everything work on OS X? + are the GPG signatures fine? + are the checksums correct? + is there a source archive? + can the source archive really be built? (NB This requires a "mvn install" first time) + is there a correct LICENSE and NOTICE file in each artifact (both source and binary artifacts)? + does the NOTICE file contain all necessary attributions? + have any licenses of dependencies changed due to upgrades? if so have LICENSE and NOTICE been upgraded appropriately? + does the tag/commit in the SCM contain reproducible sources?
[VOTE] Apache Jena 3.11.0 RC1
Hi, Here is a vote on a release of Apache Jena 3.11.0. This is the first proposed release candidate. The deadline for the vote is Tuesday, 23rd April, 2019 at 17:00 UTC Release changes: 37 JIRA: https://s.apache.org/jena-3.11.0-jira == Changes of note: JENA-1691 : Metric services for Fuseki Sean Ryan JENA-1664, JENA-1665, JENA-1673 SDB improvements including performance of OPTIONAL, MINUS Graham Triggs JENA-1686 Set Dyadic#getL() and Dyadic#getR() return type to Graph Jan Martin Keil JENA-1674 : Fix mishandling negative xsd:floats in TDB2 JENA-1644 : ParameterizedSparqlString Empty List fix Greg Albiston Improvements to TDB1 and TDB2 handling bad I/O during transaction commit. == Updates commons compress 1.17 -> 1.18 libthrift 0.10.0 -> 0.12.0 jsonld-java 0.12.1 -> 0.12.3 Additionally, control the version of Jackson: 2.9.8 due to CVE's fileupload 1.3.3 -> 1.4 slf4j -> 1.7.25 -> 1.7.26 (CVE upgrade) new: io.micrometer: 1.1.3 and recursive dependencies: org.hdrhistogram:HdrHistogram:jar:2.1.9 (BSD-2-Clause) org.latencyutils:LatencyUtils:jar:2.0.3 (BSD-2-Clause) Release Vote Everyone, not just committers, is invited to test and vote. Please download and test the proposed release. Staging repository: https://repository.apache.org/content/repositories/orgapachejena-1029 Proposed dist/ area: https://dist.apache.org/repos/dist/dev/jena/ Keys: https://svn.apache.org/repos/asf/jena/dist/KEYS Git commit (browser URL): https://github.com/apache/jena/commit/4b2f7f32c041 Git Commit Hash: 4b2f7f32c0410cca6636b58a89b51d5eb56f247e Git Commit Tag: jena-3.11.0 Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open until at least Tuesday, 23rd April, 2019 at 17:00 UTC If you expect to check the release but the time limit does not work for you, please email within the schedule above with an expected time and we can extend the vote period. Thanks, Andy Checking needed: + does everything work on Linux? + does everything work on MS Windows? + does everything work on OS X? + are the GPG signatures fine? + are the checksums correct? + is there a source archive? + can the source archive really be built? (NB This requires a "mvn install" first time) + is there a correct LICENSE and NOTICE file in each artifact (both source and binary artifacts)? + does the NOTICE file contain all necessary attributions? + have any licenses of dependencies changed due to upgrades? if so have LICENSE and NOTICE been upgraded appropriately? + does the tag/commit in the SCM contain reproducible sources?
Re: Towards Jena 3.11.0
thank you for the link Andy. glad I asked. I will try to keep track of release dates here: http://www.lotico.com/index.php/Apache_Jena On Fri, Apr 19, 2019 at 6:44 PM ajs6f wrote: > https://semver.org/ > > If, for example, we needed to make a quick release for an urgent bugfix, > it would be appropriate to increment only the "micro" or "patch" number. > > ajs6f > > > On Apr 19, 2019, at 1:33 PM, Marco Neumann > wrote: > > > > any particular reason why you add the 0 at the end? > > > > Jena 3.11 would be sufficient > > > > I have seen it in previous releases as well but there is no need to do > > so. is there a build tool that requires this? > > > > Marco > > > > On Fri, Apr 19, 2019 at 5:45 PM Andy Seaborne wrote: > >> > >> OK - I'll prepare Jena 3.11.0. > >> > >> Given the national holidays around this time, be better to have the vote > >> run into next week. > >> > >> Andy > >> > >> On 17/04/2019 21:29, Aaron Coburn wrote: > >>> Also +1 to releasing 3.11 soon and addressing these other issues in > 3.12. > >>> (But either way is fine with me) > >>> > >>> Aaron > >>> > >>> On Wed, Apr 17, 2019 at 6:47 AM wrote: > >>> > +1 to releasing 3.11.0 as described and not loading it up any further. > > ajs6f > > On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > > > We seem to be trying to do too much in one release. As ever, people > get > > busy. > > > > https://s.apache.org/jena-3.11.0-jira > >36 JIRA > > > > including fixes like JENA-1657 "Close response stream of http > connections". > > > > While not a major problem at the moment, it can start to cause > blockage > > for other work. > > > > We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > > immediately start on 3.12.0. I can RM 3.11.0 and have some time to > help > > with a 3.12 ... hoping to get it all done during May. > > > > Or we could just accept a delay to 3.11.0. > > > > It is the usual tension between perfect and timely with volunteer > time! > > > > While my preference is release 3.11.0 now and start 3.12.0, either > is OK > > for me. > > > > Thoughts? > > > > Andy > > > > On 03/04/2019 21:16, Andy Seaborne wrote: > >> We have three major streams outstanding. > >> Have I missed anything? > >> > >> 1/ GeoSPARQL > >> 2/ Prometheus metrics > >> 3/ SurroundQueryParser > >> > >> == GeoSPARQL > >> > >> Greg - apologies for being tardy on this one. It looks in good > shape. > >> Did you hear from anyone after the request for feedback? > >> > >> This is two modules: geosparql-jena and geosparql-fuseki > >> > >> A suggestion for how to proceed if you have the time for 3.11.0 is > that > >> we include these basically as-is and remove jena-spatial from Fuseki > >> which we have been signalling for a while. > >> > >> Suggestion: > >> > >>jena-geosparql > >>jena-fuseki/jena-fuseki-geospatial > >> > >> and under org.apache.jena.geosparql and > org.apache.jena.fuseki.geosparql > >> > >> It would have to be maven. > >> > >> Documentation: > >> This does not have to timed with the release though desirable to > have > >> some instructions on the website. > >> > >> Looking the modules, it has its own specialised Fuseki incarnation > with > >> command line arguments and also internally a system wide > configuration. > >> maybe, later, we might want to merge the Fuseki setup but exactly > how > >> and whether separate is better for users due to the specialised > nature > >> can wait. Release should get feedback after it is incorporated - > >> "release early, release often". > >> > >> Greg - how does that sound? > >> > >> PMC - having more eyes on this would be helpful. > >> > >> If the timing is OK, we can work on details on the ticket JENA-664 > (or > >> email on dev@). > >> > >> == JENA-1691 : Prometheus metrics > >> > >> This is getting there. We have the code worked out, the packaging > needs > >> a bit of discussion; importantly it is missing L changes due to > >> BSD-binaries in the combined jars mean some L changes. > >> > >> == JENA-1690 : SurroundQueryParser > >> > >> Looks like this is ready and waiting for someone to merge it. > >> > >> > >> With all that, it looks like some things to sort out. > >> > >> We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with > >> whatever is ready, including getting things in and expect to further > >> refine, then advance the timing on 3.12.0. > >> > >> Thoughts? > >> > >> Andy > > > > >>> > > > > > > > > -- > > > > > > --- > > Marco Neumann > > KONA > >
Re: Towards Jena 3.11.0
https://semver.org/ If, for example, we needed to make a quick release for an urgent bugfix, it would be appropriate to increment only the "micro" or "patch" number. ajs6f > On Apr 19, 2019, at 1:33 PM, Marco Neumann wrote: > > any particular reason why you add the 0 at the end? > > Jena 3.11 would be sufficient > > I have seen it in previous releases as well but there is no need to do > so. is there a build tool that requires this? > > Marco > > On Fri, Apr 19, 2019 at 5:45 PM Andy Seaborne wrote: >> >> OK - I'll prepare Jena 3.11.0. >> >> Given the national holidays around this time, be better to have the vote >> run into next week. >> >> Andy >> >> On 17/04/2019 21:29, Aaron Coburn wrote: >>> Also +1 to releasing 3.11 soon and addressing these other issues in 3.12. >>> (But either way is fine with me) >>> >>> Aaron >>> >>> On Wed, Apr 17, 2019 at 6:47 AM wrote: >>> +1 to releasing 3.11.0 as described and not loading it up any further. ajs6f On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > We seem to be trying to do too much in one release. As ever, people get > busy. > > https://s.apache.org/jena-3.11.0-jira >36 JIRA > > including fixes like JENA-1657 "Close response stream of http connections". > > While not a major problem at the moment, it can start to cause blockage > for other work. > > We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > immediately start on 3.12.0. I can RM 3.11.0 and have some time to help > with a 3.12 ... hoping to get it all done during May. > > Or we could just accept a delay to 3.11.0. > > It is the usual tension between perfect and timely with volunteer time! > > While my preference is release 3.11.0 now and start 3.12.0, either is OK > for me. > > Thoughts? > > Andy > > On 03/04/2019 21:16, Andy Seaborne wrote: >> We have three major streams outstanding. >> Have I missed anything? >> >> 1/ GeoSPARQL >> 2/ Prometheus metrics >> 3/ SurroundQueryParser >> >> == GeoSPARQL >> >> Greg - apologies for being tardy on this one. It looks in good shape. >> Did you hear from anyone after the request for feedback? >> >> This is two modules: geosparql-jena and geosparql-fuseki >> >> A suggestion for how to proceed if you have the time for 3.11.0 is that >> we include these basically as-is and remove jena-spatial from Fuseki >> which we have been signalling for a while. >> >> Suggestion: >> >>jena-geosparql >>jena-fuseki/jena-fuseki-geospatial >> >> and under org.apache.jena.geosparql and org.apache.jena.fuseki.geosparql >> >> It would have to be maven. >> >> Documentation: >> This does not have to timed with the release though desirable to have >> some instructions on the website. >> >> Looking the modules, it has its own specialised Fuseki incarnation with >> command line arguments and also internally a system wide configuration. >> maybe, later, we might want to merge the Fuseki setup but exactly how >> and whether separate is better for users due to the specialised nature >> can wait. Release should get feedback after it is incorporated - >> "release early, release often". >> >> Greg - how does that sound? >> >> PMC - having more eyes on this would be helpful. >> >> If the timing is OK, we can work on details on the ticket JENA-664 (or >> email on dev@). >> >> == JENA-1691 : Prometheus metrics >> >> This is getting there. We have the code worked out, the packaging needs >> a bit of discussion; importantly it is missing L changes due to >> BSD-binaries in the combined jars mean some L changes. >> >> == JENA-1690 : SurroundQueryParser >> >> Looks like this is ready and waiting for someone to merge it. >> >> >> With all that, it looks like some things to sort out. >> >> We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with >> whatever is ready, including getting things in and expect to further >> refine, then advance the timing on 3.12.0. >> >> Thoughts? >> >> Andy > >>> > > > > -- > > > --- > Marco Neumann > KONA
Re: Towards Jena 3.11.0
any particular reason why you add the 0 at the end? Jena 3.11 would be sufficient I have seen it in previous releases as well but there is no need to do so. is there a build tool that requires this? Marco On Fri, Apr 19, 2019 at 5:45 PM Andy Seaborne wrote: > > OK - I'll prepare Jena 3.11.0. > > Given the national holidays around this time, be better to have the vote > run into next week. > > Andy > > On 17/04/2019 21:29, Aaron Coburn wrote: > > Also +1 to releasing 3.11 soon and addressing these other issues in 3.12. > > (But either way is fine with me) > > > > Aaron > > > > On Wed, Apr 17, 2019 at 6:47 AM wrote: > > > >> +1 to releasing 3.11.0 as described and not loading it up any further. > >> > >> ajs6f > >> > >> On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > >> > >>> We seem to be trying to do too much in one release. As ever, people get > >>> busy. > >>> > >>> https://s.apache.org/jena-3.11.0-jira > >>> 36 JIRA > >>> > >>> including fixes like JENA-1657 "Close response stream of http > >> connections". > >>> > >>> While not a major problem at the moment, it can start to cause blockage > >>> for other work. > >>> > >>> We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > >>> immediately start on 3.12.0. I can RM 3.11.0 and have some time to help > >>> with a 3.12 ... hoping to get it all done during May. > >>> > >>> Or we could just accept a delay to 3.11.0. > >>> > >>> It is the usual tension between perfect and timely with volunteer time! > >>> > >>> While my preference is release 3.11.0 now and start 3.12.0, either is OK > >>> for me. > >>> > >>> Thoughts? > >>> > >>> Andy > >>> > >>> On 03/04/2019 21:16, Andy Seaborne wrote: > We have three major streams outstanding. > Have I missed anything? > > 1/ GeoSPARQL > 2/ Prometheus metrics > 3/ SurroundQueryParser > > == GeoSPARQL > > Greg - apologies for being tardy on this one. It looks in good shape. > Did you hear from anyone after the request for feedback? > > This is two modules: geosparql-jena and geosparql-fuseki > > A suggestion for how to proceed if you have the time for 3.11.0 is that > we include these basically as-is and remove jena-spatial from Fuseki > which we have been signalling for a while. > > Suggestion: > > jena-geosparql > jena-fuseki/jena-fuseki-geospatial > > and under org.apache.jena.geosparql and > >> org.apache.jena.fuseki.geosparql > > It would have to be maven. > > Documentation: > This does not have to timed with the release though desirable to have > some instructions on the website. > > Looking the modules, it has its own specialised Fuseki incarnation with > command line arguments and also internally a system wide configuration. > maybe, later, we might want to merge the Fuseki setup but exactly how > and whether separate is better for users due to the specialised nature > can wait. Release should get feedback after it is incorporated - > "release early, release often". > > Greg - how does that sound? > > PMC - having more eyes on this would be helpful. > > If the timing is OK, we can work on details on the ticket JENA-664 (or > email on dev@). > > == JENA-1691 : Prometheus metrics > > This is getting there. We have the code worked out, the packaging needs > a bit of discussion; importantly it is missing L changes due to > BSD-binaries in the combined jars mean some L changes. > > == JENA-1690 : SurroundQueryParser > > Looks like this is ready and waiting for someone to merge it. > > > With all that, it looks like some things to sort out. > > We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with > whatever is ready, including getting things in and expect to further > refine, then advance the timing on 3.12.0. > > Thoughts? > > Andy > >>> > >> > > -- --- Marco Neumann KONA
Re: Towards Jena 3.11.0
OK - I'll prepare Jena 3.11.0. Given the national holidays around this time, be better to have the vote run into next week. Andy On 17/04/2019 21:29, Aaron Coburn wrote: Also +1 to releasing 3.11 soon and addressing these other issues in 3.12. (But either way is fine with me) Aaron On Wed, Apr 17, 2019 at 6:47 AM wrote: +1 to releasing 3.11.0 as described and not loading it up any further. ajs6f On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: We seem to be trying to do too much in one release. As ever, people get busy. https://s.apache.org/jena-3.11.0-jira 36 JIRA including fixes like JENA-1657 "Close response stream of http connections". While not a major problem at the moment, it can start to cause blockage for other work. We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and immediately start on 3.12.0. I can RM 3.11.0 and have some time to help with a 3.12 ... hoping to get it all done during May. Or we could just accept a delay to 3.11.0. It is the usual tension between perfect and timely with volunteer time! While my preference is release 3.11.0 now and start 3.12.0, either is OK for me. Thoughts? Andy On 03/04/2019 21:16, Andy Seaborne wrote: We have three major streams outstanding. Have I missed anything? 1/ GeoSPARQL 2/ Prometheus metrics 3/ SurroundQueryParser == GeoSPARQL Greg - apologies for being tardy on this one. It looks in good shape. Did you hear from anyone after the request for feedback? This is two modules: geosparql-jena and geosparql-fuseki A suggestion for how to proceed if you have the time for 3.11.0 is that we include these basically as-is and remove jena-spatial from Fuseki which we have been signalling for a while. Suggestion: jena-geosparql jena-fuseki/jena-fuseki-geospatial and under org.apache.jena.geosparql and org.apache.jena.fuseki.geosparql It would have to be maven. Documentation: This does not have to timed with the release though desirable to have some instructions on the website. Looking the modules, it has its own specialised Fuseki incarnation with command line arguments and also internally a system wide configuration. maybe, later, we might want to merge the Fuseki setup but exactly how and whether separate is better for users due to the specialised nature can wait. Release should get feedback after it is incorporated - "release early, release often". Greg - how does that sound? PMC - having more eyes on this would be helpful. If the timing is OK, we can work on details on the ticket JENA-664 (or email on dev@). == JENA-1691 : Prometheus metrics This is getting there. We have the code worked out, the packaging needs a bit of discussion; importantly it is missing L changes due to BSD-binaries in the combined jars mean some L changes. == JENA-1690 : SurroundQueryParser Looks like this is ready and waiting for someone to merge it. With all that, it looks like some things to sort out. We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with whatever is ready, including getting things in and expect to further refine, then advance the timing on 3.12.0. Thoughts? Andy
