[OpenLayers-Dev] OpenLayers 2.4 Release

Christopher Schmidt crschmidt at metacarta.com
Wed May 30 10:46:51 EDT 2007

On Wed, May 30, 2007 at 04:17:45PM +0200, Andreas Hocevar wrote:
> Hi,
> On 5/29/07, Christopher Schmidt <crschmidt at metacarta.com> wrote:
> >Bug reports can be filed in Trac, under the 2.4 version.
> 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? 

To be blunt: No, I don't think so.

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.

For the record, MetaCarta has, in the past, needed a newer version of
OpenLayers at a time that was inconvenient to the project as a whole.
What we did in those cases is the same as we do in cases where we are
using a release version: we export the build of OpenLayers, with
appropriate documentation of the version, into our local svn, and our
build process uses that local SVN. I'm assuming that a similar process
is going to be maintained for Mapbuilder -- if it's not, I'd be
interested to know how you plan to integrate OpenLayers into your code 
base from a technical standpoint to see if there isn't something we can
do to make things work for you.

> We are using
> this feature in Mapbuilder, and it would be great if we could ship the
> upcoming 1.5alpha2 release of Mapbuilder (scheduled for Jun 8) with a
> stable release of OpenLayers instead of a patched trunk version.

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.

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? With this explanation in hand, we can make a
better call on how to move forward. 

Christopher Schmidt

More information about the Dev mailing list