Thinking through some necessary changes to our VCL suite

At a recent meeting with the VCL team here at Developer Express, I led a discussion on what we might do over the next few months to drive the native VCL products forward. This meeting was also a result of some other discussions I've been having with various interested VCL customers.

In essence, it seemed to me that we need to streamline how we approach the development and releases of the VCL components, especially with regard to the changed market for third-party VCL components. We're spending too much time -- time that could be spent on implementing new functionality -- in supporting old compilers and operating systems. We need to move forward with the new features coming out from CodeGear in the Delphi and VCL space otherwise we'll be left behind. We need to rationalize what we have as products: stop selling some, freeze others, concentrate on producing what customers need now and in the near future in the native component space. After all, we've been given some very clear directions from CodeGear about what's going to be happening to Delphi over the next couple of years, so it's well past time we align with them. We also need to provide a roadmap of sorts for our VCL customers, so that they can know we're still driving forward with our VCL products and when they can see new functionality appearing.

Issues that I see are:

• Releases are too often seen as just "maintenance" releases, we need to separate them (classify them?) as major/minor, upgrade or update, new versus maintenance.
• We need to get on a regular release schedule like our .NET suites that emphasizes something new appearing every quarter to every four months. That means committing to three or four major releases a year (and by "major" I mean a release with major new functionality or a new product). And, in between major releases, maybe two or three minor bug-fix releases.
• Alongside that we should explore the possibility of turning some individual products into subscriptions. This of course reinforces the need for a regular release cycle and for several updates per product per year.
• We must simplify what we support in terms of environments, that is, compilers, run-times, OSes, and the like. For example, I was amazed to find we currently support compilers all the way back to Delphi 5 (this was released in 1999 remember, and is no longer supported by CodeGear). Every possibility or combination we have means more testing time, more support time, more time taken with other things apart from writing new code.
• To a lesser extent, we could rationalize the versions of our own products that we support. I say "to a lesser extent" because in general we don't suffer too much from time taken by supporting very old versions of QuantumGrid for example.

The discussion we had covered all of this and more. In the end we came to some conclusions and also some action items.

• We will start to use the three/four major releases per year development plan. For internal logistical reasons, we will offset the major VCL releases from the .NET releases by a month or so.
• Action item: decide which future build will be the first "major" release under the new release plan. Quite probably this will be the release that contains ExpressSkins.
• The next release (build 27, due next week) will be the last one that officially supports Delphi 5 and 6 or C++Builder 5 and 6. You will of course still get technical support as you always have for these compilers; it's just that we will no longer actively use them or do any testing for them after build 27. (We won't of course be stripping out version-specific code from these components, so it's likely that future builds will continue to work with these older compilers for a while.) That means build 28 will support Delphi 7, 2005, 2006, and 2007, as well as C++Builder 2006 and (eventually -- we're still waiting) 2007.
• The next release (again, Build 27) will be the last one that officially supports Windows 2000. We argued about this back and forth at some length, but we finally decided that Win2K had too many deficiencies with regard to painting for us to spend so much time in trying to circumvent them. Action item: OK, some valid comments below are forcing me to reconsider this particular point, so we'll have to discuss further how we can avoid issues where we rely on some OS functionality that's just not available in Win2K. Graceful degradation, in other words.
  
• Along with these last two decisions, build 27 will continue to be available and maintained in minor versions for the indefinte future in order to fix minor bugs for these deprecated compilers, run- times, and operating system.
• Action item: come up with suggestions for new functionality for the next few major releases after the ExpressSkins release (this is still in beta, of course). Publish this list as a roadmap.
• Action item: decide which individual products could benefit from being subscriptions. It seems clear that Express QuantumGrid is one of those, but which others?
• Action item: research when to drop support for Delphi 7. After Highlander, perhaps?

Now I know that, although some of these items will be welcomed by our VCL community, some are going to cause concern. Please feel free to comment here or to email me with feedback. Lots of this is not set in stone and, if there are some good ideas, we're certainly willing to tweak.

Free DevExpress Products - Get Your Copy Today