New proposed release cycle for IcedTea-Web

[Danesh Dadachanji]

On 22/05/12 01:08 PM, Deepak Bhole wrote:
> * Jiri Vanek<jvanek at redhat.com>  [2012-05-22 11:42]:
>> On 05/22/2012 05:22 PM, Deepak Bhole wrote:
>>> Hi Everyone,
>>>
>>> The past, IcedTea-Web releases have been rather sporadic and I would like
>>> to address this with a firm release cycle.
>>>
>>> I was thinking that from here on, we do a forced release every 4-6
>>> months, with branching happening 3 weeks before release.
>>>
>>> Whichever period we pick, the release date will be firm. The only
>>> exceptions allowed will be critical blockers/regressions. If features do
>>> not make it in before branching, they get pushed to next release.
>>>
>>> With 6 months, the next release will be on September 4th 2012.
>>> With 4 months, the next release will be on July 3rd 2012.
>> With 6months I will be able to finish SplashScreen, with 4 I'm afraid I will not finish it in time :(
>>
>
> How about 5-mo for this one since it is rather short notice? With 5, we
> would release on August 7th and branch around July 17th, so just below 2
> months from now for branch.
>

I'm fine with having shorter release cycles as long as the process does not require _that much_ work. As far as I understand, the main 
annoyance is going through the regression tests [1] so if this is the case, 4-6 month release cycles are fine by me. IMO 6 months is 
fine just so that distro packagers don't have to go through more hassle, on the condition that we run through regression tests more often!

[1] which IMHO should be done more often than every 4 months anyways. I would say after X changesets (perhaps feature-related 
changesets only).

>>>
>>> I had 6 months in mind initially, but given the pace at which things are
>>> moving, I think 4 is more suited in the short-term for the next 2-3
>>> releases.
>> So my suggestion here is 4-6 according to features :)
>
> I think that would contradict the notion of non-negotiable release
> cycles. An open-ended "4-6 according to features" once again starts to
> drag us into feature based releases which I would like to avoid as it
> has not worked for us in the past.
>

+1 for having fixed dates too, this way the regression dates are gone through at least once every 4-6 months.

Cheers,
Danesh