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 <aj...@apache.org> 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 <a...@apache.org> 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&N changes due to > > > BSD-binaries in the combined jars mean some L&N 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 > > >
