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

[Christopher Schmidt]

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,
-- 
Christopher Schmidt
MetaCarta