Re: [Tiki-devel] Tiki 7 minor releases schedule

[Filipus K. <ch...@gm...>]

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