Development Roadmap

We have received several requests for a development roadmap, so that users can predict when various features are likely to hit, enabling them to decide when to adopt or upgrade fMRIPrep with some foresight of the challenges they're likely to face. Unfortunately, the current development approach makes it difficult.

fMRIPrep is currently (as of March 2019) developed with a very small team, and there are no people on full-time fMRIPrep support. As a result, it's difficult to predict our capacity to implement various features, and the development of a long-term roadmap itself would be a significant time sink that redirects effort from tool development. At the same time, the actual features that get implemented are most often a function of bug reports and contributor interest, which makes the accuracy of any roadmap we could sketch out somewhat dubious.

So we're working toward a long-term stable strategy, and we're very happy to have contributor input in that direction. We consider this a community project, and interested members of the community are welcome to contribute as their interests, abilities and time permit.

Release philosophy

Our small team also makes the notion of stable releases a difficult one. Under semantic versioning, X.Y.Z release numbers are described as having a major (X), minor (Y) and patch (Z) number. For larger teams, or projects with slower turnover, minor releases (e.g., 1.2.0) would indicate a level of stability for a set of features, and new features would target the 1.3.0 release. Meanwhile bugs found in 1.2.0 would be fixed and 1.2.1 would be released.

This is beyond our resources at present. Instead, we treat patch releases as indicating mostly bug fixes as well as small feature improvements. Minor releases indicate a fairly major update in functionality that users should be aware of. For example, a user using a release in the 1.1.x series should carefully read the 1.2.0 changelog to understand what's changed. (It's a good idea to read the changelog whenever upgrading, as a matter of fact.) However, there is no fundamental difference between the development process that goes into minor and micro version increments.

Our hope is that each release is usable, and our general recommendation is that users start with the most recent release. As they test it on their data, they can contribute bug reports and possibly fixes. Once their issues are fixed, we recommend that they stick with that version as they collect more data, only upgrading again when new bugs are found. And when users upgrade, we recommend that they re-run fMRIPrep on all of their data, not just the ones that produced the bugs.