On Wed, Feb 5, 2014 at 10:29 AM, Anis KADRI <anis.ka...@gmail.com> 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. Ian On Feb 5, 2014 7:03 AM, "Ian Clelland" <iclell...@google.com> wrote: > > > 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? > > > > > > 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. > > >
