Agreed! I didn't see that either until now.
On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams <to...@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" <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? >> > > >> >> > > >> > >>
