I'd like to see feature releases more often, but I wouldn't want to have that if it means less stability.
If using the version scheme x.y.z I'd like to see z used as bugfix only releases (fast release process, no RC and perhaps pre-determined release dates) and y as non-breaking feature releases (release process as-is) and z as breaking feature releases. Best case scenario would be that bugfix releases would be less of a burden to release and at the same time reducing the burden of a feature release as it could focus on new features only. /Björn 2010/2/24 Bart van den Eijnden <bart...@osgis.nl>: > 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 <zac.spit...@gmail.com> 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 >>> <crschm...@metacarta.com> 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 >>>> Dev@openlayers.org >>>> http://openlayers.org/mailman/listinfo/dev >>>> >>> >>> >>> >>> -- >>> Zac Spitzer - >>> http://zacster.blogspot.com >>> +61 405 847 168 >>> _______________________________________________ >>> Dev mailing list >>> Dev@openlayers.org >>> http://openlayers.org/mailman/listinfo/dev >>> >> >> >> >> -- >> Ivan Grcic >> _______________________________________________ >> 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
