Re: Towards release 3.1.0

[Andy Seaborne <an...@apache.org>]

OK - I'll go ahead as time permits.

[[
The process might be a bit intermittent depending on the network 
connectivity while travelling.  I'm going into the office this coming 
week ... which in my case involves UK->US.
]]

     Andy

On 29/04/16 21:08, Dave Reynolds wrote:
> +1
>
> Dave
>
> On 29/04/16 17:45, A. Soroka wrote:
>> +1 from this non-committer to holding the cache work for now. A simple
>> on-off switch seems absolutely requisite, and preferably we would have
>> fine-grained controls. The sudden appearance of an always-on cache
>> like this would represent really surprising new behavior for
>> integrators. Also, from the discussion on the PR in question [1] it
>> seems to me that there are still some questions of design.
>>
>> [1] https://github.com/apache/jena/pull/95
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>>> On Apr 29, 2016, at 12:38 PM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>> I'd like to go ahead with 3.1.0.
>>>
>>> The work on a query cache for Fuseki [*] was tested by Osma and found
>>> to be useful. There was also feedback on configuration and bounding
>>> the resources consumed by the caches.  Without the ability to
>>> configure it (including turn it off) I don't think that putting it in
>>> right before a release is a good idea.  There are is still some
>>> discussion to be had about the detailed design goals.
>>>
>>> So what I suggest is release Jena 3.1.0 now as-is, and start a
>>> testing/evaluation phase for a configurable cache.
>>>
>>> As a cache is most important under load, and Fuseki is used in
>>> deployed and public facing systems, I'm concerned that we block
>>> people picking up all the other things in 3.1.0.  I think it would be
>>> good to get wider testing via users@.  That will take time. (And then
>>> if people don't test it until after its in a release ... well, we can
>>> only do our best.)
>>>
>>>     Andy
>>>
>>> [*]
>>> https://issues.apache.org/jira/browse/JENA-626
>>> https://github.com/apache/jena/pull/95
>>>
>>> On 18/04/16 12:35, Osma Suominen wrote:
>>>> Hi Andy!
>>>>
>>>> I'm happy with the current state of Jena and would support a release.
>>>> This time I've been more diligent in using recent snapshots so there
>>>> should be less chance of problems that surface only around release
>>>> time.
>>>>
>>>> I have no outstanding work that I want to do for jena-text currently.
>>>> JENA-1134/AnalyzingQueryParser (which you can consider including in the
>>>> release notes) was the major item for me since the previous release,
>>>> plus some bugfixes that were done earlier.
>>>>
>>>> -Osma
>>>>
>>>> On 18/04/16 13:44, Andy Seaborne wrote:
>>>>> Version 3.1.0 has quite a few good things in it1
>>>>>
>>>>> I think it is about time we released it.
>>>>>
>>>>> So this is a first ping for anything you want to get done for it.
>>>>>
>>>>> As for timing - I can RM it sometime in the next few weeks though it
>>>>> will have to fit around other things.
>>>>>
>>>>>      Andy
>>>>>
>>>>> -------------------------------------------
>>>>>
>>>>> * New custom functions and aggregate functions
>>>>>    Added:
>>>>>    + afn:sprintf (contribution from Alessandro Seganti)
>>>>>    + The XQuery/XPath Functions and Operators "math:" functions
>>>>>    + Custom aggregates for stdev etc. (also STDEV etc as keywords).
>>>>>
>>>>> * RC features in 3.0.1:
>>>>>    + In-memory transactional dataset (Adam Soroka )
>>>>>    + SPARQL extension for CONSTRUCT Quads (Qihong Lin)
>>>>>
>>>>> * OSGi fixes (Jaroslav Pullmann)
>>>>>
>>>>> * Upgrades:
>>>>>    jsonld-java : 2.8.2
>>>>>      jackson 2.6.3
>>>>>    slf4j 1.7.20
>>>>>    dexx collections 0.2 -> 0.6 (OSGi)
>>>>>
>>>>> * DatasetGraphs & transactions
>>>>>
>>>>> * New module jena-cmds
>>>>>
>>>>> * Logging - log4j marked <optional>
>>>>>
>>>>> * Fuseki: Multiple service per file, shared datasets
>>>>>
>>>>> * JSON result fix type: "literal" not "type": "typed-literal"
>>>>>
>>>>> * Space saving when parsing (FactoryRDF)
>>>>>    Parsing RDF now saves space by partial interning RDFTerms
>>>>>    created during a each parser run.
>>>>
>>>>
>>>
>>
>