[OpenLayers-Dev] OpenLayers 2.4 Release

[Cameron Shorter]

I'm agree with Chris on this one.
Openlayers should not be releasing a 2.4.0.1 release.

The next Mapbuilder release will be an alpha version or a release 
candidate. For this we don't require a stable version of Openlayers. A 
RC of OL will be fine. Less desirable, but still acceptable will be a 
patched version of OL.

For a final release of Mapbuilder (which is still a while off) we should 
be aiming to have a stable release of OL to match it. We can coordinate 
this as we get closer to the release deadline.

Andreas Hocevar wrote:
> Hi,
>
> On 5/30/07, Christopher Schmidt <crschmidt at metacarta.com> wrote:
>   
>> On Wed, May 30, 2007 at 04:17:45PM +0200, Andreas Hocevar wrote:
>>     
>>> I opened a trac ticket too short before 2.4 release
>>> (http://trac.openlayers.org/ticket/726), containing a patch to support
>>> toggle type buttons in button panels.
>>> Do you think this can still be pulled into a 2.4 release?
>>>       
>> We don't do x.y.z releases, in general. It's possible we can make an
>> exception for Mapbuilder -- I'd need to be convinced. One thing that
>> would be important for me to understand is how Mapbuilder plans to do
>> management of their OpenLayers build, since it seems clear to me that
>> this kind of thing is going to happen all the time, and I can't be in
>> favor of something that has us constantly trying to release for other
>> software projects.
>>     
>
> Sure, I understand that. It was just an idea in a team meeting a few
> weeks ago to use an OpenLayers release for a Mapbuilder release. But
> that is by no means a must.
>
>   
>> I think your options are either 'a trunk version' or 'a patched 2.4'. In
>> either case, applying the 'patches' can be as simple as a couple dozen
>> lines in a js file: look at the beginning of init() in
>> http://tilecache.org/demo.html for an example. I basically end up
>> patching OL in some way for every demo I create -- and that's okay,
>> because Javascript is friendly to that, and when the next version comes
>> out, I can remove those local modifications.
>>     
>
> Yes, we could use a local copy of an OpenLayers release and apply
> patches to it, of course with documented reference to the according
> OpenLayers trac tickets.
>
>   
>> I'm not the only person who gets a voice in this, but I'd be against it
>> without a compelling explanation of why other technical means can't
>> suffice. Imagine a situation where Sarissa needs a patch in order for
>> Mapbuilder to ship: How would you proceed? Can this same process be
>> applied to OpenLayers?
>>     
>
> Ties with OpenLayers are somewhat stronger than with Sarissa. We are
> trying to contribute features to OpenLayers that fit better there than
> in Mapbuilder. My main concern is not about OpenLayers releases for
> Mapbuilder, but for useful features making their way into OpenLayers
> generally. And therefore I am happy when my patches make it into
> OpenLayers trunk. But that is just my opinion, other Mapbuilder
> developers might think different about it.
>
> Regards,
> Andreas.
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>
>   


-- 
Cameron Shorter
Systems Architect, http://lisasoft.com.au
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254