cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: [Android] 4.x branch
Date Tue, 20 May 2014 18:43:34 GMT
+1

I think it's the right time to do this. I'm certainly motivated by
pluggable webviews, and if we're going to break things, then lets do them
all at once. (And write a good upgrade guide :) )

We can create a 4.x branch at the same point as the 3.6.x branch, and merge
upstream changes in until it's ready for release as 4.0.0.

JS is a good question -- we had to make a lot of coordinated changes
between the platforms and the common JS code for Cordova 3.0; is there a
similar call for JS changes with 4.0? That is, are there cross-platform
concerns with a 4.0 release; interfaces that all platforms will need to
conform to?

Along those lines, are there other cross-platform features that we want to
start working on, that would prompt a 4.0 release of other platforms as
well? Or is this where we start getting serious about
independently-released platforms?


On Tue, May 20, 2014 at 2:03 PM, Joe Bowser <bowserj@gmail.com> wrote:

> Hey
>
> So, the more I look at what's happening in Android, the more things
> that I see that we have to break, the more I want to create a 4.x
> branch.  The reasons for this are obvious:
>
> - LinearLayout vs RelativeLayout
> - Pluggable Weviews
> - Changing the App plugin to something else (CoreEvents, similar to
> Windows)
> - Abstracting custom URIs OUT of WebViewClient/WebChromeClient for
> shared logic (see the SMS/hangout bug)
> - etc, etc
>
> Basically, we're going to need to make some changes to Android.  We're
> going to pass mobile spec and the JUnit tests, and everything will be
> fine, but I think we really need to start putting these fixes in the
> 4.x branch and assume that we're going to land this in 4.0.
>
> I'm thinking that we might want to do this with JS as well for those
> changes as well, but I'm not sure.
>
> Thoughts??
>
> Joe
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message