Bart van den Eijnden <bart...@osgis.nl> schrieb:
>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 _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
