cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Date Wed, 05 Feb 2014 15:25:45 GMT
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.  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.

-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