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 <[email protected]> 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 <[email protected]> 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 - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
