-1 to "just break it" Developers using Cordova still are frequently having to deal with massive breaking changes every few releases. Developing and (even more so) maintaining an app built using Cordova is actually pretty painful sometimes... Even for me, and I am on this list and see this stuff coming.
If you think the new way is the best one true way, then leave the default as is and *educate* people as to why. The File API is one of the *most* used plugins of the core plugins. Breaking that big a percentage of existing apps at 3.4 seems unwise to me. I know, I know... The plugins are separately versioned and this will be a major version change.. Tell me, has any dev had to know or really even been exposed to the fact that the plugins have their own versions yet? It's not like we have a package.json file with deps in it all semvered based on "last known good" versions like a node app might. I doubt many devs even know you *can* install a particular version of a plugin. If when installing a plugin we had --save-deps or something, and that used versions and kind of pinned the app to that major version, then a breaking version change might not break as many hearts ;) - tommy On 06/02/2014 2:26 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. 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? > > >> > > >
