<br><br>On Friday, November 4, 2011, Andreas Hocevar <<a href="mailto:ahocevar@opengeo.org" target="_blank">ahocevar@opengeo.org</a>> wrote:<br>> Hi,<br>><br>> 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.<br>
<br>Yes, non API breaking changes can continue landing in master. A v3 branch would be for changing APIs (removing deprecated objects is part of that).<br><br>> 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.<br>
><br>> 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.<br>
><br>
> 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.<br>
<br>Do you see this work happening in the master branch, or in a v3 branch?<br><br><br><br>Here's my opinion:<br><br>We're talking about new APIs, but are we talking about major renovations, or a few tweaks here and there? It's not clear to me what people have in mind, what people will be able to do, etc. Creating a v3 branch and having people send pull requests would make things more concrete. We will see where this leads us to, and if we need compatibility layers, etc.<br>
<br>Thanks,<br>