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 _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
