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 >> >> >> > > >
