<div>Hey all,</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Tom</div><div><br><div class="gmail_quote">On Fri, Nov 4, 2011 at 1:08 PM, Xavier Mamano (jorix) <span dir="ltr"><<a href="mailto:xavier.mamano@gmail.com">xavier.mamano@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
>From outside OpenLayers: I 100% agree with Andreas Hocevar.<br>
<br>
In particular is very easy to keep in the trunk deprecated code in separated<br>
source files.<br>
<br>
The code sprint allow to start major changes in the code, an example: 2.11<br>
<br>
I am very interested in V3 but I'll keep looking at the trunk 2.12 until it<br>
is put in the fridge.<br>
<br>
Xavier Mamano<br>
<div><div></div><div class="h5"><br>
<br>
<br>
Andreas Hocevar-2 wrote:<br>
><br>
> Hi,<br>
><br>
> a lot of work has been done this year to make the library faster and<br>
> smaller. All this is basically work that was originally planned for the<br>
> 3.0 version, but was implemented without breaking the API.<br>
><br>
> In my opinion, for a new major version, the main goal is to create a slick<br>
> API. I am also in favor of making components like the Format classes<br>
> conveniently usable outside the context of an OpenLayers map (e.g. to<br>
> support 3D mapping projects like WebGL Earth), as well as making<br>
> OpenLayers geometry functions an optional component that can entirely be<br>
> replaced e.g. by JSTS, similar to what we now do with projections and<br>
> proj4js.<br>
><br>
> Once we have the slick API, a compatibility layer can be created to make<br>
> upgrading easier. Ideally, the new API should be created during a code<br>
> sprint. Looking together at a whiteboard and designing the new API on it<br>
> 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<br>
> now in a development branch. But instead of merely removing code, I'd be<br>
> in favor of an approach that moves deprecated functions/methods to<br>
> separate files, so that they can still be included in a build. By doing<br>
> so, we're already one step closer to the compatibility layer I mentioned<br>
> above, and I don't think it means much extra effort.<br>
><br>
> Andreas.<br>
><br>
> On Nov 4, 2011, at 11:04 , Peter Robins wrote:<br>
><br>
>> what's the status with v3 in general? We had a v3 branch last year on<br>
>> github, but it seems to have disappeared. There's a page on trac<br>
>> <a href="http://trac.osgeo.org/openlayers/wiki/Release/3.0" target="_blank">http://trac.osgeo.org/openlayers/wiki/Release/3.0</a> but contains a lot<br>
>> of duff links.<br>
>><br>
>> There was quite a bit of discussion last year about it, but this year<br>
>> it hardly seems to have been mentioned.<br>
>> _______________________________________________<br>
>> Dev mailing list<br>
</div></div>>> Dev@.osgeo<br>
<div class="im">>> <a href="http://lists.osgeo.org/mailman/listinfo/openlayers-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/openlayers-dev</a><br>
><br>
><br>
><br>
> --<br>
> Andreas Hocevar<br>
> OpenGeo - <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>
> Expert service straight from the developers.<br>
><br>
> _______________________________________________<br>
> Dev mailing list<br>
</div>> Dev@.osgeo<br>
> <a href="http://lists.osgeo.org/mailman/listinfo/openlayers-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/openlayers-dev</a><br>
><br>
<font color="#888888"><br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1803224.n2.nabble.com/v3-branch-on-GitHub-for-deprecation-API-changes-tp6959931p6963456.html" target="_blank">http://osgeo-org.1803224.n2.nabble.com/v3-branch-on-GitHub-for-deprecation-API-changes-tp6959931p6963456.html</a><br>
Sent from the OpenLayers Dev mailing list archive at Nabble.com.<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Dev mailing list<br>
<a href="mailto:Dev@lists.osgeo.org">Dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/openlayers-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/openlayers-dev</a><br>
</div></div></blockquote></div><br></div>