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