Thanks for the update Rob. Yes, I understand it is mostly a question for one of the committers to have time to put it all together, assuming nothing goes wrong and people agree that a service increment is a good idea. There are a significant number of fixes in the transactional code as Andy points out and we feel more comfortable with that than what we have in 2.7.1 although they mostly affect TDB's ability to recover during a crash. On the testing front, we just got one of our clients to run a scalability test (meaning they run with a large starting repository and fire up multiple users to perform read/write activities) and they have not observed any regressions compared to 2.7.1 and a slight overall speed improvement (something like 6%, not stellar, but most importantly not slower)
Simon From: Rob Vesse <[email protected]> To: "[email protected]" <[email protected]> Date: 09/12/2012 02:19 PM Subject: Re: 2.7.4 release? Any release should take in the region of a week assuming everyone is happy with the state of the code and people have been testing continuously. There's no reason a release should take much longer than that unless any serious issues crop up during the process It's mainly a question of someone having the free time to shepherd the process through because it is somewhat time consuming in parts Rob On 9/12/12 11:04 AM, "Simon Helsen" <[email protected]> wrote: >Well, we had two timescales in mind: > >Either very quick, i.e. sometime next week :-) That would give our >verification testers enough time to get decent coverage before release >and >would just be sufficient to get legal aspects out of the way. I realize >that would have been ambitious either way, but in the past, I have >observed with Jena 2.7.2 and Jena 2.7.3, it took you guys no more than a >week from the intend of releasing to getting it cleared and voted on. >Anyhow, I was kind of assuming that wouldn't be possible anymore, so the >next window of opportunity for us would be December at which point our >integration testers would probably be in a position to hammer the thing >and there would be plenty of room for legal. > >I realize this is volunteer effort, so we are not demanding anything of >course, but 2.7.3 was not good enough for us in terms of stability and >2.7.1, well, we can live with it, but it is not as robust under crashes >as >2.7.4. Also, it seems slightly faster > > > > >From: >Andy Seaborne <[email protected]> >To: >Simon Helsen/Toronto/IBM@IBMCA >Cc: >[email protected], Philippe P Mulet <[email protected]> >Date: >09/12/2012 01:41 PM >Subject: >Re: 2.7.4 release? > > > >Simon, > >What timescale are you working to? > > Andy > >On 12/09/12 15:26, Simon Helsen wrote: >> 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 >> >> >> > > >
