Hi, We've all seen how he died sadly the first attempt to v3.
What I meant is that it is easier to move forward dragging compatibility than keeping alive two branches. If it slows the development of 2.12, then perfect: long live V3! Xavier Tom MacWright-3 wrote: > > Hey all, > > A compatibility layer that lets people treat a v3 like a v2 is something > that those people should build: I don't think that it should be a high > priority for core developers. People have had five years of stated API > stability: I think that's excessive and severely handicaps the ability to > iterate. If people want to stay with a v2 API, there can be backports of > bugfixes, but I really think that forcing better APIs to act like older > ones is not a good focus. > > That said, I'm not in favor of a code sprint being the only way to > collaborate, though that may be a personal preference towards 'just doing > it' and collaborating over GitHub - and that this is a relatively > worldwide-dispersed team. For that matter, collaboration on Modest Maps > and > Leaflet has included basically zero facetime between committers and has > gone well just in issues on GitHub. Maybe there's some other factor that > requires more structuring here, but unless there is, I think a more nimble > approach to a v3 could be a good thing. > > Tom > > On Fri, Nov 4, 2011 at 1:08 PM, Xavier Mamano (jorix) < > xavier.mamano@> wrote: > >> Hi, >> >> >From outside OpenLayers: I 100% agree with Andreas Hocevar. >> >> In particular is very easy to keep in the trunk deprecated code in >> separated >> source files. >> >> The code sprint allow to start major changes in the code, an example: >> 2.11 >> >> I am very interested in V3 but I'll keep looking at the trunk 2.12 until >> it >> is put in the fridge. >> >> Xavier Mamano >> >> >> >> Andreas Hocevar-2 wrote: >> > >> > Hi, >> > >> > a lot of work has been done this year to make the library faster and >> > smaller. All this is basically work that was originally planned for the >> > 3.0 version, but was implemented without breaking the API. >> > >> > In my opinion, for a new major version, the main goal is to create a >> slick >> > API. I am also in favor of making components like the Format classes >> > conveniently usable outside the context of an OpenLayers map (e.g. to >> > support 3D mapping projects like WebGL Earth), as well as making >> > OpenLayers geometry functions an optional component that can entirely >> be >> > replaced e.g. by JSTS, similar to what we now do with projections and >> > proj4js. >> > >> > Once we have the slick API, a compatibility layer can be created to >> make >> > upgrading easier. Ideally, the new API should be created during a code >> > sprint. Looking together at a whiteboard and designing the new API on >> it >> > is much easier with everybody focussed and in the same room. >> > >> > Removing deprecated code is a low hanging fruit and could already be >> done >> > now in a development branch. But instead of merely removing code, I'd >> be >> > in favor of an approach that moves deprecated functions/methods to >> > separate files, so that they can still be included in a build. By doing >> > so, we're already one step closer to the compatibility layer I >> mentioned >> > above, and I don't think it means much extra effort. >> > >> > Andreas. >> > >> > On Nov 4, 2011, at 11:04 , Peter Robins wrote: >> > >> >> what's the status with v3 in general? We had a v3 branch last year on >> >> github, but it seems to have disappeared. There's a page on trac >> >> http://trac.osgeo.org/openlayers/wiki/Release/3.0 but contains a lot >> >> of duff links. >> >> >> >> There was quite a bit of discussion last year about it, but this year >> >> it hardly seems to have been mentioned. >> >> _______________________________________________ >> >> Dev mailing list >> >> Dev@.osgeo >> >> http://lists.osgeo.org/mailman/listinfo/openlayers-dev >> > >> > >> > >> > -- >> > Andreas Hocevar >> > OpenGeo - http://opengeo.org/ >> > Expert service straight from the developers. >> > >> > _______________________________________________ >> > Dev mailing list >> > Dev@.osgeo >> > http://lists.osgeo.org/mailman/listinfo/openlayers-dev >> > >> >> >> -- >> View this message in context: >> http://osgeo-org.1803224.n2.nabble.com/v3-branch-on-GitHub-for-deprecation-API-changes-tp6959931p6963456.html >> Sent from the OpenLayers Dev mailing list archive at Nabble.com. >> _______________________________________________ >> Dev mailing list >> Dev@.osgeo >> http://lists.osgeo.org/mailman/listinfo/openlayers-dev >> > > _______________________________________________ > Dev mailing list > Dev@.osgeo > http://lists.osgeo.org/mailman/listinfo/openlayers-dev > -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/v3-branch-on-GitHub-for-deprecation-API-changes-tp6959931p6963616.html Sent from the OpenLayers Dev mailing list archive at Nabble.com. _______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev
