About the Infragistics product release cycles

We get a lot of questions in the forums and other places from customers asking about when our next product release will be, and I understand that it can be frustrating when you don't get a concrete answer.  To help give everyone a better idea of when they can expect releases, I thought I would write a post about our product release cycle from a fairly macro level and hopefully help clear up some of the mystery.

For most of our products including NetAdvantage for ASP.NET, NetAdvantage for Windows Forms, the NetAdvantage for .NET bundle, we release on a three-times per year cadence, usually once in the late winter/early spring, once in the summer and once in the fall.  In between each of those releases, we are releasing both public and private patches and hotfixes.

For some of our products such as NetAdvantage for WPF and NetAdvantage for JSF, we use a longer development cycle with two volume releases per year, generally once in spring and once in fall.  And finally, for our TestAdvantage product, we generally release about 1 month behind the NetAdvantage for .NET releases.

When customers ask when is the next release going to be, often how specific we can be our answer depends on where we are in our development cycle.  As a corporate policy we generally do not talk about release dates very specifically until we are very close to the actual release.  The reason for that is, like most software products, we ship when we meet internal quality metrics, and there is always a chance that we will find show stopper bugs late in the cycle that will force a delay.  What we very much want to avoid is setting the expectation of shipping on a specific date which customers plan around, then having to change that date of we find something that would prevent us from shipping. 

Why does it take you so long to release support for new Microsoft products/platforms?

For quite some time it has been our policy to say that we release support for new Microsoft products and platforms 60 to 90 days after Microsoft RTM's the new product or platform.  Why so long?  Primarily it is because, believe it or not, Microsoft does continue to make changes to their bits pretty much up to the final RTM release.  This means that even though we can spend lots of time up front testing our tools on early versions of the products, in the end we have to run our full suite of test beds on their release bits in order to ensure compatibility, and yes, we do find issues that crop up only in the release builds of the new Microsoft products and platforms.  Add on top of that that many times, especially when dealing with Visual Studio, we are playing in areas of the bits that may have not gotten as much love during Microsoft's Beta/CTP releases as they needed, and it can be pretty challenging to support a new platform.

But why do you ask me to report compatibility bugs?  Don't you guys test?  I don't want to be your guinea pig.

As much testing as we do, we are consistently amazed at how our customers use the tools in the product, and as much as we try, it would really be impossible for us to think of and test every single possible scenario.  The reason we ask you to report compatibility issues is precisely because we want to know if you're using the tools in scenarios or configurations that we have not identified.  Reporting compatibility issues to us gets the issue on our radar so that we can evaluate and prioritize a fix for the issue.

 

Hopefully this demystifies the general release cycle we operate in and why sometimes it seems like we can't be as specific as you would like us to be.  I would love to hear your feedback on the release cycle and how you think we could improve our communication to you.