Hi, I also think we should release more often (again). See my comments inline.
Christopher Schmidt wrote: > On Tue, Sep 15, 2009 at 01:00:12PM -0600, 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. >> With an increasing number of libraries depending on OpenLayers, I'd say the benefit of being able to point to a recent *release* that the library is known to work with outweighs the drawbacks of possible 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). >> Sounds like a plan. > > I'd be interested in what number of people are running applications off > trunk. I'm sure that some of our contributors are -- for example, anyone > who has written a patch is probably at least running with a version which > includes their patch -- but my experience is that I don't see a lot of people > asking for help who aren't running on 2.8 currently. > At least, with more time passing after a release, we see replies to users reporting issues like "this has been fixed since x.y, please use the current trunk version" more frequently. > Generally, when I start seeing that change is when I start suggesting > it's time for a release :) > > I'm not against maintenance releases, though. When OpenLayers was under > more rapid development, the longer process was more neccesary. Now that > we're in a mostly static state -- minor features and bugfixes, rather than > significant new core developments -- there's not as much risk to including > most of the current changes to trunk in a release without a ton of testing. > So are you suggesting to make the release process for minor releases (x.y) less onerous, instead of doing more frequent maintenance releases (x.y.z) with a less time consuming release process? I think that there may be users who want an extremely stable version. Such users would choose a x.y release, whereas users who need new features would rather use a x.y.z release. Regards, Andreas. -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers. _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
