Supported IDEs for our VCL products going forward

After getting lots of excellent feedback on my post about the roadmap for our VCL products (thanks to everyone who responded!) and having had some discussion internally, we’ve extended the list of IDEs that we will be supporting in the future for our VCL subscriptions.

photo © 2008 milolovitch69 | more info (via: Wylio)As I stated before, we have to do this in order to be more efficient in our releases and to maximize our ability to provide new functionality in those releases. Supporting the current list of 14 IDEs and compilers (well, I think it’s 14: Delphi 6, 7, 2005, 2006, 2007, 2009, 2010, XE; C++Builder 6, 2006, 2007, 2009, 2010, XE — yep, 14) means that a great deal of time and resources are spent in testing and supporting our products for these compilers and the 8 versions of the VCL that they require (well, I think it’s 8, etc). We’re also cognizant of the fact that it’s very likely that Embarcadero will be releasing another new version of RAD Studio this year and that this release may even have 64-bit support. At that point, the amount of effort needed for supporting and testing our controls will be quite alarming: 18 compilers. That’s 10 different versions of the VCL, to put it another way. Frankly, our VCL team would rather be writing new functionality to make our subscriptions even more valuable.

Since many people, rightly or wrongly, didn’t view RAD Studio XE as a worthy upgrade from the 2010 release, we’ve added back Delphi and C++Builder 2010 into the mix. The list of supported IDEs and compilers will be 7:

• Delphi 7 (just because it’s still very popular — come on, people, upgrade already)
• Delphi & C++Builder 2007 (the last ANSI string version)
• Delphi & C++Builder 2010 (the current popular version for Unicode support)
• Delphi & C++Builder XE (just because it’s the latest version)

(And the relevant RAD Studio versions as well, of course.) Let’s call these the primary compilers, and the others not mentioned the secondary compilers.

Now, what does this exactly mean? Firstly it means that the primary compilers are the only ones we shall officially support. If you find an issue using a secondary compiler then our first step will be to see if it’s reproducible with the “nearest” primary one (actually we’ll probably test either side). Secondly it means that, although secondary compilers are no longer supported, it’s unlikely we shall be removing any $IFDEFs that cover them, at least not immediately. It’s likely therefore that the products will continue to work with the secondary compilers at least for a while, but it’s not guaranteed. Indeed, it’s more than likely that the code will start to “decay” for those compilers: some things will continue to work and others will break as we add new features and fix other bugs.

As I said before, we have to simplify our mix for our VCL products. This means subscriptions, no individual products, and a reduction in the number of environments we have to support. Once this is fully in place, we can move on to provide even more great functionality and features for VCL.

Free DevExpress Products - Get Your Copy Today