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 15:50:27 GMT
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