cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Date Wed, 05 Feb 2014 21:33:00 GMT
I think this approach is our best path forward right now. There's no
immediate need to break apps for developers; it was a convenient time in
the development of the plugin, but we can easily wait for another
convenient time. There seems to be no compelling reason to couple a
breaking change with the other updates to the plugin.

I'm committing changes to the plugin now to support this; the actual "set
the default so things don't break" code is isolated to a single commit, so
that it's super easy to revert or change later if we decide we don't like
it.

I've asked around here, nobody on the Google team has any objections to
this path.

Anis, you were also agreeing with me previously about breaking sooner
rather than later: Are you okay now with separating the two issues, just
doing the API upgrade now, and starting the process of promoting the new
locations before we change the default sometime in the next 12 months?



On Wed, Feb 5, 2014 at 11:19 AM, Joe Bowser <bowserj@gmail.com> wrote:

> Agreed! I didn't see that either until now.
>
> On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams <tommy@devgeeks.org> wrote:
> > Of course, while writing my rant, Ian has summarized a great proposal.
> >
> > +1 to the below!
> > On 06/02/2014 2:51 am, "Ian Clelland" <iclelland@chromium.org> wrote:
> >
> >> On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny <mmocny@chromium.org>
> wrote:
> >>
> >> > Honestly, my opinion on this: Leave the default as-is for now.  We've
> >> just
> >> > made huge changes to the API, which may have bugs / implications we
> >> haven't
> >> > fully thought through.
> >>
> >>
> >> That's a really good point. If we do this right now, we have two huge
> >> changes going on at the same time, and we will have to deal with a lot
> of
> >> heat for bugs *as well* as the location change.
> >>
> >>
> >> >  Lets let a subset of users upgrade to the new
> >> > $MAJOR version, and a subset of those add the new preference.  In a
> later
> >> > release, we can make the switch -- by then, maybe we will have more
> >> > solutions for migrating.
> >> >
> >> > Also, this is a nice to have, but its obviously been a situation that
> >> devs
> >> > have been living with for years.
> >> >
> >>
> >> That is something that I was thinking about last night. If we go with
> #3;
> >> put in a safe default, then we could spend a year if we wanted to
> promoting
> >> hard the "please please please switch to the better version" position.
> >>
> >> Then we could announce long in advance that we're changing the default,
> or
> >> that we're removing the default, and when we're ready, bump the major
> again
> >> to 2.x and do it.
> >>
> >> This might be the best situation for the developers, and it's no worse
> for
> >> the users than the situation right now. It's less than optimal for the
> >> "cordova ecosystem", but the ecosystem may be harmed more by angry
> >> developers leaving the platform than by continuing to place files where
> >> they are now.
> >>
> >>
> >> So this proposal would be:
> >>  - Don't revert the changes made on dev
> >>  - Don't rename the plugin
> >>  - Add a default which places files exactly where they are now
> >>  - Bump the major version
> >>  - Start fixing bugs in the new code. (without being distracted by the
> >> storage location change)
> >>  - Start blogging about the issue with storage locations, and encourage
> >> people to change (but don't force them to do anything yet)
> >>  - In a year, or when we feel that a sufficient mass of developers have
> >> gotten the message, broadcast that we're removing the default. (or
> changing
> >> it, if we're very confident in our plugin upgrade paths)
> >>  - Some months after that, make the change. (and hopefully not be
> >> distracted by bugs in the underlying plugin code) Bump the major version
> >> again.
> >>
> >> I'm actually pretty happy with that; we think that the current situation
> >> isn't great, but it doesn't seem to be actively hurting the ecosystem.
> And
> >> any developers who think otherwise will now have the tools to fix it for
> >> their own apps.
> >> Eventually we can be more opinionated about it, and the plugin will be
> more
> >> robust, so devs shouldn't be *as* angry as if we switched it right now.
> >>
> >> Ian
> >>
> >>
> >> > -Michal
> >> >
> >> >
> >> > On Wed, Feb 5, 2014 at 10:13 AM, sebb <sebbaz@gmail.com> wrote:
> >> >
> >> > > On 5 February 2014 14:55, David Kemp <drkemp@google.com> wrote:
> >> > > > My concern with any automated fix is that we have no idea what
> files
> >> > > belong
> >> > > > to an app.
> >> > > > The default is to just toss everything in the root.
> >> > > > Files may be user data that is shared between apps, config files
> or
> >> > temp
> >> > > > files. The developer probably knows what to migrate - we don't.\
> >> > >
> >> > > The app must tell the library what file names are involved.
> >> > > So unless the same API is used for files that are supposed to remain
> >> > > in the root, it should be possible to know what needs to move.
> >> > >
> >> > > It  may still prove too difficult to implement the merge, but
> perhaps
> >> > > there is some scope for adding something to help the developers.
> >> > >
> >> > > For example, the code could check if there is a file with the same
> >> > > name in the old location, and log a message if so.
> >> > > There may be other checks that would help mitigate the breakage.
> >> > >
> >> > > >
> >> > > > On Wed, Feb 5, 2014 at 9:05 AM, sebb <sebbaz@gmail.com>
wrote:
> >> > > >
> >> > > >> On 5 February 2014 13:20, David Kemp <drkemp@google.com>
wrote:
> >> > > >> > -1 to merging reads. That just sounds like a horrible
thing to
> >> > debug.
> >> > > >>
> >> > > >> Seems to me that developers using the plugin will have to
> implement
> >> > > >> something similar in order to make it easier for their users.
> >> > > >>
> >> > > >> Would it not be better to spend the time getting it right
once,
> for
> >> > > >> the benfit of all developers, rather than hoping they each
get it
> >> > > >> right?
> >> > > >>
> >> > > >> I don't know what is involved here, so this is theoretical.
> >> > > >> But I believe that compatibility should only be broken if
> necessary.
> >> > > >> Also that fixing a problem at source is usually a lot cheaper
> than
> >> > > >> requiring downstream developers/users to do so.
> >> > > >> There are lots more of them, so any extra effort they have
to
> expend
> >> > > >> is multiplied many times.
> >> > > >> In other words, the cost-benefit should not just look at
the
> >> immediate
> >> > > >> cost to the project.
> >> > > >>
> >> > > >> > +1 to 'go big or go home'. Break it now. Break it obviously.
> >> > > >>
> >> > > >> But I agree that breakage - if decided on - should be obvious.
> >> > > >>
> >> > > >> >
> >> > > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref <
> >> jsoref@blackberry.com>
> >> > > >> wrote:
> >> > > >> >
> >> > > >> >> Is it impossible to have reads merged from both
locations, but
> >> > > writes go
> >> > > >> >> to the new location, and when a write completes
in the new
> >> > location,
> >> > > >> delete
> >> > > >> >> the old one?
> >> > > >>
> >> > >
> >> >
> >>
>

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