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" <iclell...@chromium.org> wrote:
> On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny <mmo...@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 <seb...@gmail.com> wrote: > > > > > On 5 February 2014 14:55, David Kemp <drk...@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 <seb...@gmail.com> wrote: > > > > > > > >> On 5 February 2014 13:20, David Kemp <drk...@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 < > jso...@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? > > > >> > > > > > >
