cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: 4.0 Sprint Tasks (Another "Hey, let's ship 4.0.x soon" post)
Date Thu, 11 Dec 2014 19:24:31 GMT
On Wed Dec 10 2014 at 8:03:10 AM Andrew Grieve <agrieve@chromium.org> wrote:

> On Sun, Dec 7, 2014 at 11:53 PM, Joe Bowser <bowserj@gmail.com> wrote:
>
> > Hey
> >
> > After messing with the JS for a week, I decided for now to stop work on
> > MozillaView.  I think I've managed to prove that the concept is at least
> > possible, but I really feel that it's still too unstable to actually show
> > past a demo/POC at this time.  We've definitely learned some lessons, and
> > I'll probably write a blog post on them soon, and pick up work in the new
> > year.
> >
> > That said, we should really concentrate on shipping 4.0 in January, we
> > should do the following:
> >
> > 1. Bump up the targeted version to 5.0
> >
>
> We should do this for 3.7.0
>
>
I don't think we should bother with 3.7.0 at this point.  Adobe employees
have a week left before they disappear for Winter Break, and I'm sure other
people are going to vanish as the holidays approach.  We should probably
just go straight to 4.0 in January?


>
> > 2. Allow for users to target KitKat for Quirks Mode (I'm not kidding,
> > Quirks mode is back.  Chrome is the new IE! WTF MAN!)
> >
>
> Please confirm whether you mean something different from letting users
> specify targetSdkVersion.
>

No, That's what I meant.  I just remembered that we do allow users to do
this.

>
>
> > 3. Get the gradle work in.  MUCH FASTER! LESS SPAM! WOW!
> >
>
> Woohoo! It's actually already been shipping in master / 3.6.0 behind an
> environment variable (ANDROID_BUILD=gradle).
>
>
I don't like the whole ship behind an environment variable practice, since
it seems like a way to avoid having to create a feature branch.  I really
wish that Gradle was a feature branch thing.  Also, can one of you guys
smack the Android team on the back of the head for that Gradle dependency
hell they created?  The whole point of Gradle is to bundle the dependencies
locally so they don't blow up when you change the system, and the plugin
severely screws with that.


>
> > 4. Get the JUnit tests working with Gradle/Android Studio.  I don't think
> > this is a 4.0 task per-se, but we should do it right after 4.0 is
> released.
> > 5. Stare at the pie chart wishing that 9 was 5.  (Anyone who knows our
> > deprecation policies knows EXACTLY what I'm talking about).
> >
> > I do have one API change I want to make.  I want to rename the
> > CordovaWebView interface CordovaWebInterface so that it's obvious that
> it's
> > an interface.  Since people using the old CordovaWebView embedded feature
> > are going to have to do a find/replace on the XML, this doesn't really
> > matter.  Of course, the people using this feature may beg to differ.  If
> > you're using this feature, and you care about it still working with your
> > current code, PLEASE TEST 4.0 NOW.
> >
>
> Agree it's super confusing, especially when merging master->4.0.x. However,
> doing this would have the potential to break any plugin that is holding a
> reference to the webview. I think the other changes are more breaking
> anyways though (in particular, having it not be an Android View anymore).
>
>
Yeah, I did have that argument earlier.  Then I did the Refactor/Rename in
Eclipse and realized that if I can do a Find/Replace, other people can as
well and get their plugins working.  I do want the interface to reference a
view ideally, but that's an optional feature (and one that Crosswalk
doesn't do AFAIK).

BTW: Have people adopted Android Studio for Cordova dev yet? I'm probably
going to in the new year, since that's what everyone's using now and
Eclipse has been totally deprecated.

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