I couldn't have said it better myself. -1 to "just break it".
On Wed, Feb 5, 2014 at 8:00 AM, Tommy Williams <to...@devgeeks.org> wrote: > -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? >> > >> >> > >>
