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 <marco.neum...@gmail.com> 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 <a...@apache.org> 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 <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 >>>>> >>>> >>> > > > > -- > > > --- > Marco Neumann > KONA
