Supported IDEs for our VCL products going forward

12 January 2011

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.

Flex Array on Production Line 2photo © 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.

12 comment(s)
Marcos Silveira

I am user of Delphi 2009 Enterprise and I use the DevExpress QuantunGrid.

I intend to migrate to the VCL Subscription, but this news does not support Delphi 2009 as I do?

I ask that you include the Delphi 2009 on this list.


Marcos A Silveira

12 January, 2011
Byron Baynham_1

Thanks for listening with regard to supporting Delphi 2010.  Great news.

12 January, 2011
Iskandar Achmad

This is good news for Delphi2010 users.

I also think that DevExpress need to be more concentrate on new functionality rather than having to test so many compilers/IDE just to fix/tune-up minor feature in the components.

12 January, 2011

If u change sales model to subscription model.

Please release more stable product or

Customers will need to purchase subscripition for ever year(forever) only for getting bug fixes.

Current ur prodcut has many bugs as long as i see support center issues.

13 January, 2011

Because after subscription period expires, I cant get any bug fixes after that, right???

13 January, 2011
Claudio Piffer

Hi Julian


I agree with your choice a 100%.



13 January, 2011
Michael Schmidlkofer

Can we get a subscription option that doesn't have the controls bundled? I only care about Win32 development.

13 January, 2011
Julian Bucknall (DevExpress)

Marcos: And where does that end? Sorry to be so frank but if we make an exception for the 2009 compilers then we should make an exception for the 2006 compilers, and the 2005 compiler, and pretty soon we're back to where we started: supporting 14 compilers. We already know that we can't support the full panoply of compilers AND produce regular deep compelling upgrades at the same time. If we add more people to the team in order to do both, the cost will go up for everyone. How much more are you willing to pay in order to have both?

vanilla610: It may sound trite but every complex piece of software has bugs. It's got nothing to do with whether it's sold as a subscription or not. The old way of selling our controls (buy a version and get updates to that version free for life) meant that we'd have to create an upgradable version every year or 18 months in order to continue to get a revenue stream, even if that upgrade was minor. I prefer moving towards a "get all the updates and upgrades you can stomach for a set annual price" plan rather than a "here's a couple of new features, we changed the version number, so you have to pay us for them, hurrah" scheme. At least you know what the price is for a subscription and can budget for it.

vanilla610 (bis): Look to how we manage this in our .NET space. We are still providing bug fixes to v2009.3 for example, even though the current version is v2010.2. Obviously, at some point, it becomes impossible to provide a bug fix to an older version since it requires some new code introduced in a later version.

Michael: just don't install them. They are free, mainly because we stopped supporting and providing EWF and wanted our customers to have an upgrade path, even though it would be a difficult one to follow.

Cheers, Julian

13 January, 2011
Michael Schmidlkofer

Thanks, didn't realize the controls were bundled gratis.

I'm quite happy with the changes. While I've only purchased a handful of the components you offer so far, I can see me using many of the others, and I certainly don't mind a subscription if it means the ones I do use won't wither on the vine for lack of financial incentive to keep them updated.

The only thing that would be more awesome would be a modern CodeRush for Delphi =D

13 January, 2011
David Brennan

Good move, Delphi 2010 is a bit too fresh to be just dropped.

I've said this before, but by jove I'm going to keep saying it until it gest done! Please fix ExpressBars to handle visual inheritance properly. It is ludicrous that we have been forced to use Toolbar2000 and TBX2000 instead despite using DevExpress for pretty much all visual components and it also means we are missing out on a lot of value with skinning, built in menus, print dialogs, etc. See:

13 January, 2011
john smiths

Your choice is 100% correct........

19 January, 2011
Martin Lawrence

Thanks for listening!  

Support for D2010 is excellent news.

19 January, 2011

Please login or register to post comments.