Picking up on an old thread, IIRC we had quite a bit of consensus on this. So what do we do for 2.9, a quick maintenance release or a normal full-blown release?
Best regards, Bart On Sep 15, 2009, at 9:00 PM, Tim Schaub wrote: > Hey- > > We periodically discuss releasing on a fixed schedule. Though a few > releases have come close to sticking to a schedule, my impression is > that it has been a tough to pull off. It is also my impression that the > release process feels onerous enough to enough people that we are > collectively avoiding it. > > I'm interested in discussing doing more "maintenance" releases between > minor releases. What exactly would change about the release process [1] > I'm not sure, but the goal would be to make it less work overall. > > While this might seem extreme, I'm curious what people would think about > kicking out maintenance releases *without* going through the release > candidate cycle. Taking this further, a maintenance release manager > could decide to stick to a schedule and release even if there were known > regressions. > > While the result may be something of questionable value, I do think it > would bring some benefits. My impression is that there are a lot of > people running applications off the trunk currently. I also imagine a > fair number are running "sandbox" functionality or their own patched > versions. Having more frequent releases would not be that much > different than pegging applications to a specific version of the trunk. > I think all would agree this is safer than having an application run > off the head revision. > > This would also have the benefit for contributors of more quickly seeing > their contribution in an official release - potentially encouraging more > contributions. > > Obviously there would be details to work out about the process, but I > would suggest a pared down version of the major/minor release process - > with leeway for the maintenance release manager to decide on some > specifics (e.g. if all tests pass on this date, bump tickets, release, > and make notes about known issues). > > Thoughts? > Tim > > [1] http://trac.openlayers.org/wiki/Release/Procedure > > -- > Tim Schaub > OpenGeo - http://opengeo.org > Expert service straight from the developers. > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
