From: Jonny B. <jo...@ti...> - 2011-07-28 09:15:20
|
On 28 Jul 2011, at 00:17, Filipus Klutiero wrote: > Hi Jonny, > I'm not sure I understand your message well, but... > > On 2011-07-26 10:38, Jonny Bradley wrote: >> Hi Chealer and all >> >> You are correct of course - but the release schedule for 8 will be up to the release coordinator, whoever that may be (not me). > I was not suggesting anything for the content of the schedule. I just > meant to say that having no release schedule (and no volunteers) 3 > months before the time the release is supposed to happen, I consider it > risky to set 8 as the successor to 7.1. It could mean bugs in 7.1 will > stay in our stable release longer than they should. >> Any suggestions? ;) > I would like to help with releases, but I can't commit to that (for now, > and that's unlikely to change before 8). And all i meant was i'm not coordinating 8.x (but i'll code and test as much as other projects allow, of course). jb >> jb >> >> >> On 23 Jul 2011, at 07:57, Filipus Klutiero wrote: >> >>> Hi Jonny, >>> I'll leave the QT decide when proposals should be created for 7, if at >>> all. But I do have an opinion on ending 7 regular bugfix releases at >>> 7.1. Here's my thinking: >>> >>> Officially, support for Tiki x stops the second Tiki x+1 is released. >>> Therefore, if x.y is the last Tiki x release, releasing x.y at the same >>> time as x+1 is useless, as everyone will upgrade to x+1 rather than x.y. >>> So x.y has to be released some time before x+1 to make x.y's release >>> profitable. In the classic model, you assume all real users are using >>> stable releases, so there is no interest in keeping a stable branch >>> after the x.y release (disregarding security releases). Therefore, it >>> does make sense to find an ideal time before a major release when the >>> last minor release of the previous cycle should be released. So far >>> we're pretty much on the same line. >>> >>> Currently, if Tiki 8 is to be released in October, that means 3 months >>> without a bugfix release. We don't have to look very far to find a >>> bugfix release that took this long - 6.4 did (6.3 was on 12 April). And >>> ignoring 6.3, which was a security release, 6.4 took 5 months. However, >>> 6 had already had 2 bugfix releases, so was presumably more stable than >>> 7.1 will be. >>> But if we go further, we do find that after 4.1, 4.2 took 4 months. And >>> taking into account that 4.2 was a security release, the next real >>> bugfix release was 3 more months later, that is 7 months. In fact, 4.3 >>> was released just after 5.0. >>> >>> This data shows a .1 release can last for 7 months, which is more than >>> we expect 7.1 to last. So in the perspective described above, we kept >>> 4.x open for 7 months with no results, so if 7.1 is as stable as 4.1 and >>> 8 comes in October, we should close 7 with 7.1. >>> >>> On the other hand, 5 did take these 7 months to release, after 4.1. If 7 >>> should be the stable release for 7 months, do we really think that 7.1 >>> can do it, considering that 7.1 received 200 changes in a month and a >>> half? I surely hope 7.1 won't last 7 months, but as long as there is no >>> release team or release schedule for Tiki 8, it can't be ruled out. The >>> Tiki 7 cycle should really be decided together with the Tiki 8 cycle, >>> which is why I think we should have a permanent release team... :-\ >>> >>> So, I am shared on this, but I would rather play conservative and let a >>> 4.2 happen. >>> >>> BTW, some data which would be helpful to decide on QT and release >>> policies: how long does it take the QT to get "accepted" ready >>> (accepting and rejecting commits from proposals) once reviewing is done >>> vs the time it takes to just review proposed commits? And approximately >>> how long does it take to release "accepted" (run scripts, upload, etc.) >>> for a minor release? >>> >>> On 2011-07-21 12:23, jonny B wrote: >>>> Hi Sylvie (& both lists 'cos it's important) >>>> >>>> >>> [...] >>>> I'm currently of a mind that we should not do a proposals branch for >>>> 7.x and effectively close it after the release of 7.1 (which seems to be >>>> perfect according to the feedback ;). All efforts then should be on 8.x >>>> and getting code.t.o working so we can do a good job on 9.x LTS (and >>>> maybe 8.x) >>>> >>>> Anyone needing emergency fixes in 7.x should fork their own version, >>>> maybe providing patches on dev.t.o for others. >>>> >>>> Security and language fixes could be made as usual straight to >>>> branches/7.x. >>>> >>>> Just my 2¢ - what do others think? >>>> >>>> jb > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > TikiWiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > |