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. Another way of avoiding this would have been to pick a different name for this plugin. Is it too late? 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. >
