cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: 4.0 Sprint Tasks (Another "Hey, let's ship 4.0.x soon" post)
Date Thu, 11 Dec 2014 20:29:21 GMT
On Thu Dec 11 2014 at 2:51:04 PM Joe Bowser <bowserj@gmail.com> wrote:

> On Thu Dec 11 2014 at 11:46:44 AM Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > On Thu, Dec 11, 2014 at 2:24 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> > > 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?
> > >
> >
> > There's a lot of changes in 3.7.0 built up already. I don't think it'd
> be a
> > good idea to skip it.
> >
> >
> And this is where I remember that we HAVE to release 3.7.0 because of our
> six month deprecation policy.  I just think that doing a release right
> before people disappear for two weeks is a bad idea.
>
> So, 3.7.0 and 4.0.0 in January? Also, if we are doing a 3.7.0 release, we
> have some things that MUST go in prior, such as CookieManager stuff in
> CordovaWebView/AndroidWebView.
>

That sounds good -- I approve of releasing from two major version branches
at the same time, especially if we're adding very similar features to both.


> Joe
>
>
> >
> > >
> > >
> > > >
> > > > > 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.


It was on a feature branch for some time before I merged it in. The trouble
with just using feature branches for something like this is that it's very
difficult to get it to end users, and it would otherwise be a major
breaking change, with an almost-entirely untested feature. (And by that,
I'm not saying that we didn't do any testing, just that build systems and
configurations vary incredibly wildly across the developer base, and
there's just no way that any of us could uncover all of the problems before
launch, no matter how careful we try to be. The amount of testing we can do
is dwarfed by the number of developers with test cases we couldn't discover
if we wanted to.)

Putting it behind a flag meant that we could get it to early adopters,
without telling them to get a branch of of the tip-of-tree, and they could
try it out without worrying about not being able to go back if it didn't
work.

Literally everyone I talked to about this was positive, and appreciated
that we had made it possible, without making it mandatory.

</rant>

  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.
>

If I get to talk to the tools team, I'm definitely bringing that up. Even
their support matrix (that you showed me in IM) makes it look like it's
impossible to satisfy without deep inspection of package version numbers. I
think that we have a working solution to CB-8143 now, though.


> > >
> > >
> > > >
> > > > > 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.
> > >
> >
> > I've made the switch. The biggest gotcha is that you need to do a build
> of
> > the project from the command-line before importing into Android Studio.
> > This is because we don't create the .gradle files until build.js (and we
> > should just fix this and do it on create / prepare).
> >
>

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