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

[Xavier Mamano (jorix)]

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 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 .osgeo
>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>>
> 
> _______________________________________________
> 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-tp6959931p6963616.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.