cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <>
Subject Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Date Wed, 05 Feb 2014 15:37:58 GMT
On Wed, Feb 5, 2014 at 10:29 AM, Anis KADRI <> wrote:

> I also think we should break it now. It's not as if we have never broken
> anything before... keeping backward compatibility should anyways be
> preferred but in this case I think it would cause more trouble than it
> would solve.
> I say don't write any migration tools but document the changes in
> plugin.xml (<info> tag), write a blog post about it, tweet it, Google plus
> it and... Be super loud about it.
> It's not like we are breaking everything for everyone either. We have
> plugin versions for a reason.

Right, this was going to be the first test of a major version bump of a
published plugin. We want this to be a step that developers need to take
deliberately, I think.

> Another way of avoiding this would have been to pick a different name for
> this plugin. Is it too late?

Not too late; it would be some work to cherry-pick the unrelated fixes from
dev, but we could do it. Maybe we should do that anyway, and maintain an
0.x line for people who won't/cant' upgrade.


On Feb 5, 2014 7:03 AM, "Ian Clelland" <> wrote:
> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref <>
> 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?
> >
> >
> > It might be. The File API doesn't impose any sort of model for read/write
> > patterns. Reads and writes can happen anywhere in a file; we can't
> enforce
> > that a file is written out entirely in one call, so there may not be a
> > point where we can say "it's done; delete the old one".
> >
> > It's also entirely possible for multiple readers to be open on the file,
> > and for another thread to have a writer open, writing somewhere in the
> > middle of the file, so I would expect race conditions.
> >
> > This isn't *impossible*; there have been OS filesystems which do this
> for a
> > long time, but it seems to me to be a lot more work than writing a tool
> for
> > developers to use for migration, and much more error prone.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message