[OpenLayers-Dev] maintenance releases

[Andreas Hocevar]

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.