[OpenLayers-Dev] moving OL to a scheduled release cycle

[Cameron Shorter]

I'm tentatively supportive for a fixed release cycle.
A fixed schedule will make planning to use Mapbuilder easier.

I'm tentative because:
1. There is a reasonable overhead associated with a release cycle, 
(managing issues, testing etc). I'm guessing that Chris is offering to 
provide labour, so in that case this is not an issue.

2. What happens if we go through the release cycle, and find a 
show-stopper bug just before we are due to release? Do we release with 
the bug or hold off. I'd suggest we should hold off.

But overall I'm +1 for a fixed release cycle.

Christopher Schmidt wrote:
> On Thu, Jun 07, 2007 at 08:31:31AM -0400, Paul Spencer wrote:
>   
>> Schuyler,
>>
>> I'm a big fan of release-early-release-often but it seems to me that  
>> this may be a bit aggressive.  It has the advantage of pushing out  
>> stable releases very quickly but I think it has a lot of overhead.   
>> Most projects I'm familiar with have a 6 month cycle, and even that  
>> is difficult to stick with.
>>
>> I think I would prefer longer cycles, perhaps 3-4 months rather than 2?
>>     
>
> I'm of the opposite opinion: I almost think 2 months is too long.
>
> Our release schedule so far has been:
>
>  2.0: 10/01/06   (I'm not sure about these -- this is what
>  2.1: 10/05/06    trac reports, but it seems wrong.)
>  2.2: 11/15/06   (From here down is correct.)
>  2.3: 02/21/07
>  2.4: 05/29/07
>
> I know that there was a  general feeling that 2.4 was a 'long time
> coming' release: as you can see from the dates above, it was only 3
> months, but to me, it felt like it was more than a month overdue by the
> time it was out.
>
> I think that if we actually put a hard feature freeze on the code, we'll
> actually get things out to people more quickly. I do think that this
> method of development would mean we would want to establish a way to
> continue working on trunk while we're in an RC state, but I think if we
> do that, then we can get:
>  
>  * Rapid release of new features
>  * Continued development in trunk
>  * Stability testing + bugfixes on a branch
>  
> I think the result of this will be hugely beneficial for the project.  
>
> It does mean that we need to bite off smaller chunks for releases. I'm
> fine with that. I think it's good to actually establish a longer-sighted
> roadmap than we currently have, and give timelines for releases.
>
> I think four months is excessive. I'd accept 3 months, but I know from
> experience that when we go that long, it seems like a long time. If I
> were to have my way, I'd say that from today, you have 4 weeks to work
> on new features -- anything that isn't in gets bumped, and we branch and
> start testing. The features can be reviewed by people who have time and
> committed to trunk -- so development doesn't stall like it currently
> does -- but it also means that we have a hard date that people can
> expect a new release by, and it's soon. 
>
> Hell, I'm almost of the opinion that we should go for one month -- 3
> weeks of coding, one week of testing. That would essentially limit us to
> one major new feature per release -- which would lead to a shorter
> testing cycle, and features getting to users faster. But I think I'm
> alone in that one :)
>
> Regards,
>   


-- 
Cameron Shorter
Systems Architect, http://lisasoft.com.au
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254