Infusion versioning and compatibility

Sun Mar 3 23:30:32 UTC 2013

To add some more info here. If we decide to stay with option 1, perhaps we could move towards the semantic versioning spec. 
http://semver.org

Our current version scheme is actually quite close to it. The main differences are as follows: 
we have a fourth dot number
we currently don't have nightly build versions

Thanks
Justin

On 2013-02-25, at 10:24 AM, Andrew Petro <apetro at unicon.net> wrote:

> 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 versioning.
> 
> 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,
> 
> Andrew
> 
> 
> 
> 
> 
> On Sun, Feb 24, 2013 at 3:51 AM, Clark, Colin <cclark at ocadu.ca> 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.
> 
> 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
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130303/9f3f86f6/attachment.htm>