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 <[EMAIL PROTECTED]> 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 > [email protected] > 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 _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
