cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Date Wed, 05 Feb 2014 16:03:23 GMT
I couldn't have said it better myself. -1 to "just break it".


On Wed, Feb 5, 2014 at 8:00 AM, Tommy Williams <tommy@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" <mmocny@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 <sebbaz@gmail.com> wrote:
>>
>> > On 5 February 2014 14:55, David Kemp <drkemp@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 <sebbaz@gmail.com> wrote:
>> > >
>> > >> On 5 February 2014 13:20, David Kemp <drkemp@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 <jsoref@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?
>> > >>
>> >
>>

Mime
View raw message