Thanks Andy

"The changes (post TDB 0.9.3) for optimized and correct transactions are 
new and really could do with bedding down.  If you could go beyond basic 
testing that would be helpful so things get raised before a .4 release."

we are in the process of getting more comprehensive tests done, but that 
process is quite resource intensive as you can imagine. If there is no 
prospect of having a .4 release on time, it is also more difficult to 
justify. You have to see it this way: we can easily test snapshots 
(pre-releases) with our own development automated tests and some limited 
scalability tests of some of our clients. Beyond that, it becomes 
cumbersome to test snapshots because we can never get legal approval for 
these, meaning we can't bring the changes into our main development stream 
etc. We are then forced to produce custom builds and equip our testers 
with these. Nothing is impossible, but some things are more difficult and 
more importantly, take more time.

"The deprecations in jena-core could do with some inspection before a 
release because the point of deprecating them is that they can then get 
removed."

Right, however, I assume that for a .4, these APIs would just be 
deprecated and not removed, right?

"The SDB release cycle is going quite well - and doing a lightweight 
community "Release Candidate" seems to have been a success.  We have 
reports, and something has been reported that could do with investigation.
"

Right, I understand that, although I am not sure if an SDB release has to 
be a prereq for a .4 service release

"It would be nice to release LARQ as a post-incubator."

I agree, but here as well, is that really a prereq for a service release?

"Things are busy."

no doubt



From:
Andy Seaborne <[email protected]>
To:
[email protected], Philippe P Mulet <[email protected]>
Date:
09/12/2012 05:06 AM
Subject:
Re: 2.7.4 release?



On 06/09/12 21:28, Simon Helsen wrote:
> hi everyone,
>
> I was wondering if there is a chance to get a 2.7.4 release soon. There
> have been numerous fixes since 2.7.3 and unfortunately, we are not 
allowed
> to adopt a non-released snapshot. Basic internal testing seems to 
suggest
> 2.7.4 is pretty stable. Does not mean we would not find more bugs, but 
it
> would fit the frequent small service releases. As a non-committer, I 
don't
> think I can help the process (other than testing)
>
> thanks
>
> Simon
>

The changes (post TDB 0.9.3) for optimized and correct transactions are 
new and really could do with bedding down.  If you could go beyond basic 
testing that would be helpful so things get raised before a .4 release.

Quite a few JIRA have had input in the last week or so and I haven't 
managed to get a picture of where we are.  The Fuseki as a WAR file 
(JENA-201) has lots of votes.

The deprecations in jena-core could do with some inspection before a 
release because the point of deprecating them is that they can then get 
removed.

The SDB release cycle is going quite well - and doing a lightweight 
community "Release Candidate" seems to have been a success.  We have 
reports, and something has been reported that could do with investigation.

It would be nice to release LARQ as a post-incubator.

Things are busy.

I wonder if an RC phase is the best way forward.

(all) What things would ideally be done before a RC phase can start?

                 Andy



Reply via email to