+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 >
