cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: Updating FileTransfer
Date Tue, 19 Nov 2013 01:56:24 GMT
When Ian is done with his changes, even if we gave it a new name, almost
certainly in practice we would stop supporting the old one.  Just because
no one would want to put the effort into the old version any more, doubly
so because of the poor current state of those plugins and how much better
this new version is likely to be.

I see your point that it is less likely that we will push point updates to
an older version of an existing plugin, than we would to a standalone but
deprecated plugin.  So I have a suggestion:  Any willing community member
can/should fork the existing plugin and call it LegacyFileTransfer or
something like that, and that becomes the new de facto home for updates.
 It can be published in the registry, and we can point users to it from
JIRA etc, but don't officially support it.  That way, the community decides
what's worth the effort.  WDYT?


On Mon, Nov 18, 2013 at 6:51 PM, Tommy Williams <> wrote:

> I'll hate you, but I guess I'll get over it (I have a plugin that is
> basically a modified fork of file-transfer.. . gonna be a pain updating it
> now, heh).
> What happened to the suggestions for this all being a new plugin of some
> kind? Though plugins are versioned, an old version gets no bug fixes...
> On 19/11/2013 9:11 AM, "Brian LeRoux" <> wrote:
> > Answers inline.
> >
> >
> > > Does FileTransfer implement any published standard, or is it our own
> API?
> > >
> > > Nope.
> >
> >
> >
> > > Does it make sense for FileTransfer to continue to use raw FileSystem
> > paths
> > > (and *not* go through File at all?) given that the File API will soon
> be
> > > returning only relative paths and filesystem:// URLs.
> > >
> > > Consistent w/ URL scheme makes sense to me but I'll let others chime in
> > how this will break everything and our users will hate us. But remember:
> > plugins are versioned!
> >

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