On Wed, May 30, 2007 at 04:17:45PM +0200, Andreas Hocevar wrote: > Hi, > > On 5/29/07, Christopher Schmidt <[EMAIL PROTECTED]> 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. Regards, -- Christopher Schmidt MetaCarta _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
