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? -Michal On Mon, Nov 18, 2013 at 6:51 PM, Tommy Williams <to...@devgeeks.org> 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" <b...@brian.io> 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! > > >
