Infusion versioning and compatibility

Andrew Petro apetro at
Mon Feb 25 15:24:33 UTC 2013

Hi Colin,

My two cents:

I like this option best:

> 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.

I like your current versioning scheme.  It amounts to Apache-style

The Apache-style versioning scheme is well established and understood in
open source contexts. It's good shorthand for helping adopters and
integrators know what to expect.  There's no shame in breaking APIs to
produce a better product, but it's better to be able to see at a glance how
worried an adopter or integrator needs to be that something breaks on
nudging dependency versions.  So, there's value in ever better versions of
Infusion landing, and there's value in using version numbers to communicate
with adopters about what to expect as regards backwards compatibility of
those versions.  Going from 1.x to 2.0 communicates that 2.0 made some
changes to be better, and that those changes may inflict some pain on the
upgrade, and, implicitly, that in the Fluid project's judgment, the pain is
worth it for the improvement.

I for one am inclined to trust your judgment.  Congratulations on the
framework evolution and on the forthcoming Infusion releases, which I
expect will continue to be very much worth it.

Kind regards,


On Sun, Feb 24, 2013 at 3:51 AM, Clark, Colin <cclark at> wrote:

> 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.
> 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
> _______________________________________________________
> fluid-work mailing list - fluid-work at
> To unsubscribe, change settings or access archives,
> see
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list