Thanks Andy. I was going to ask about this non-incubating release, but this answers it :-)
I have been testing a 2.7.1 snapshot of earlier in the week and have found no functional problems so far. Query performance with 50+ threads is still somewhat weak, but I am going to compare the same suite in a 2.7.1. without transactions and our 2.6.3 build. I can send you the numbers once I have them. Moreover, one of our client teams are conducting a very large experiment as well (1 million+ resources/graphs) and 200+ users/threads. As expected memory consumption is higher with Tx, but still manageable. What did surprise us is that the physical store nearly doubled from 35Gb to about 70Gb. As for the issues you write below: 1) single source release is nice for our open-source approvers 2) keeping fuseki separate from apache-jena is also great. We typically only need iri-core-arq-tdb :-) 3) no opinion on 3/ and 4/ 4) LARQ: so far, we have not been using it, but we are thinking of starting with that, so having it released with 2.7.1 would be nice. If this does not happen, then, it would help if there is a clear indication with what release a given component would be compatible (that request would apply to any component which is not released with the "main" pack thanks Simon From: Andy Seaborne <[email protected]> To: [email protected] Date: 05/25/2012 09:30 AM Subject: Next apache-jena release It would be nice to make a release now we are out of incubation. I think doing the least to make the release happen is the right next step but I can be persuaded that doing more on integration of components is worth waiting for. Starting proposal: 1/ Single source release, not one per module. 2/ Two downloads: apache-jena being iri-core-arq-tdb jena-fuseki being Fuseki (==> switch off assemblies for ARQ and TDB for the release) 3/ Separate versions numbers for component, numbering as we have in svn at the moment . we haven't experimented with an uber jar yet shouldn't be any problems other than verbosity of the plugin . separate jars mean we can release updates for example, fine-tuning for final SPARQL stuff. 4/ The parent is not a separate release. If we do a single build, I can't think of a reason for a separate parent but I may have missed something. Thoughts? Any JIRA that you feel a strong need to complete and get in the next release? Paolo - what about LARQ? If it gets placed in the release, would that hamper getting incremental update released soon? Or do as a parallel release (i.e. not in apache-jena but part of the build) to get the version moved on to non-incubating. Next step: I will set up a Jenkins job to build (2.7.1-snapshot) apache-jena as a preliminary step and then disable the explicit snapshot builds of iri-core-arq-tdb. We can inspect the binary it builds ... and it will at least mean no ordering problems with snapshot builds. Andy PS And no more icu4j!
