[OpenLayers-Dev] maintenance releases

[Björn Harrtell]

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 <bartvde at 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.spitzer at 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
>>> <crschmidt at 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 at openlayers.org
>>>> http://openlayers.org/mailman/listinfo/dev
>>>>
>>>
>>>
>>>
>>> --
>>> Zac Spitzer -
>>> http://zacster.blogspot.com
>>> +61 405 847 168
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at openlayers.org
>>> http://openlayers.org/mailman/listinfo/dev
>>>
>>
>>
>>
>> --
>> Ivan Grcic
>> _______________________________________________
>> Dev mailing list
>> Dev at openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
>
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>