[OpenLayers-Dev] Re: v3 branch on GitHub for deprecation & API changes

[Tom MacWright]

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 at gmail.com> 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 at .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 at .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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20111104/70651162/attachment.html