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 <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? > >> >
