Right, but not everybody is so proficient / handy .... I've had quite a few people asking me lately when is OpenLayers 2.9 coming, since the last release was more than half a year ago.
Best regards, Bart On Feb 24, 2010, at 9:37 AM, Ivan Grcic wrote: > On Wed, Sep 16, 2009 at 12:00 AM, Zac Spitzer <[email protected]> wrote: >> i've always used trunk myself + plus some patches >> > same here, trunk + patches on some apps (on some 2.8 + patches), so it > got kinda little bit messy with time :) > > cheers > >> On Wed, Sep 16, 2009 at 5:21 AM, Christopher Schmidt >> <[email protected]> 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. >>>> >>>> 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? >>> >>> 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. >>> >>> 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. >>> >>> Regards, >>> -- >>> Christopher Schmidt >>> MetaCarta >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://openlayers.org/mailman/listinfo/dev >>> >> >> >> >> -- >> Zac Spitzer - >> http://zacster.blogspot.com >> +61 405 847 168 >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://openlayers.org/mailman/listinfo/dev >> > > > > -- > Ivan Grcic > _______________________________________________ > Dev mailing list > [email protected] > http://openlayers.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
