Infusion versioning and compatibility

[Clark, Colin]

Hi everyone,

Big new changes are happening to the core Infusion framework right now. Antranig has been hard at work improving the IoC system, and we're also in the process of designing a new version of the Renderer. These features will make it easier to develop applications with Infusion.

With all this new activity, we've started to think about the next few releases of Infusion. Our plan is to ensure that these new releases will be largely API compatible with previous versions and that existing users will have a straightforward upgrade path.

That said, some new features will break compatibility in a few of the more obscure corners of the framework. These changes will likely only affect the most advanced users, and we'll ensure that there is a clear and documented migration path for affected APIs. Most importantly, all component APIs will remain stable.

Based on our current versioning policy, backwards-incompatible changes will require a major increase in the version number of Infusion. In other words, Infusion 2.0 is coming soon.

http://wiki.fluidproject.org/display/fluid/Fluid+Versioning+Scheme

In the long run, we're excited enough of about these new framework features that we'd like to consider the possibility of more dramatically improving APIs over time. For example, we can imagine a new version of the Pager that benefits from both the improved framework and the new Renderer.

With this in mind, we'd like to balance backwards compatibility with more frequent, innovative releases. From a versioning perspective, three possible approaches have emerged:

1. Leave our versioning scheme as it is and make more frequent major releases. In this case, it's likely that Infusion 2.0, 3.0, and beyond will land within about a year.

2. Refine our versioning scheme so that APIs which have been publicly marked as deprecated can be removed after two minor releases of Infusion. We may even want to consider a time span for deprecated APIs (e.g. after one year or two minor releases, they'll be removed).

3. Replace the current versioning scheme with a more general set of guidelines for backwards compatibility. With this approach, we'd evaluate each planned release to balance API stability with innovation and incremental change. In other words, we won't have a formal policy but will carefully assess the impact of each release prior to choosing a version number.

In the end, regardless of approach, we remain committed to maintaining a stable platform on which to develop production-level applications. This will continue.

I'm curious to hear if any of these approaches stand out to you as particularly preferable.

Colin

---
Colin Clark
Lead Software Architect,
Inclusive Design Research Centre, OCAD University
http://inclusivedesign.ca