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
