1.x/2.0 compatibility and deprecation/warning schedule

[effigies]

Follow-up to discussion in #2517.

Summary

For some backwards-incompatible name changes that are being planned for Nipype 2.0, we can smooth the path forward by performing the change now, and keeping the original names as aliases. This will permit code written to target recent versions of Nipype to use the newer names, and make a couple fewer pain points for the eventual transition.

The following changes have been proposed in #2517:

• InputMultiPath -> InputMultiObject
• OutputMultiPath -> OutputMultiObject
• filename_to_list -> ensure_list
• list_to_filename -> simplify_list

On the whole, it would be good to encourage developers to transition, but we also don't want to annoy or frighten users by generating a large number of FutureWarnings or DeprecationWarnings. So I think we should attempt to form a strategy for how and when to insert warnings. This will help avoid the decision being made on a PR-by-PR basis.

I can think of two approaches:

• Do not add warnings until 2.0, and have a very short deprecation cycle, rather than immediately break everything.
• Add warnings in 2.0 alpha/beta. Eliminate old functionality at 2.0-rc1.
• Create a milestone on the 2.0 roadmap; once passed, warnings go in the 1.x series
  • If we call that milestone 1.5+, then we could add deprecations now that will not display until 1.5.

Any preference? Other ideas?