Upgrades

Saturday, February 19, 2005 09:31 AM

I'm in crunch mode, working on an upgrade for Planners for VCL. Planners, if you haven't seen it, is a component library for Delphi and C++Builder, containing several controls for displaying and editing schedules. Version 1.0 was released about a year ago - Planners' birthday is February 15th (one day after Delphi's birthday, which I haven't posted about since everybody else already has - happy birthday, Delphi).

I'm fairly proud of Planners 1.0. It's an extremely stable version, and in over a year we've no major bugs, and only a few minor bugs - all of which can be easily worked around - have been reported. There's always room for improvement, though, and this is where the next version comes in.

Releasing an upgrade is very different from releasing a 1.0 product. When planning the next version, I've encountered many issues I've been able to avoid in the first release. Some of them are totally new issues, while others could have been foreseen, and would have been better off handled even before the first version. Some are relevant to any shrink-wrapped product, while others are only relevant to libraries. If you're a developer considering releasing a commercial library, you may benefit from this post. If you're a Planners customer waiting for a new version, this post will expose some of the issues we're dealing with. Don't worry, though - we will release a new version, Real Soon Now.

The First Version

Creating a library that can be released into the wild is hard. As programmers, we're aware of the technical difficulties regarding published code. The most obvious one is quality - a publicly available library must be of the best quality, since one it's released you no longer have control over the deployment of the code. If you screw up here, you'll either drown in support calls and e-mails, or just lose customers. Since humans are prone to errors, there will always be problems with your code - plan for them, and decide on a maintenance policy. More importantly, listen to your customers, and be prepared to change that policy if it doesn't fit the market.

The quality issue, however difficult, is probably the easiest one to tackle when releasing a product, because it's so obvious. Programmers understand code quality, and while not all programmers take it seriously, I'm assuming most component developers do. Other issues are harder for programmers to handle. Think about what you expect when you buy a component library:

• Usefulness - this goes without saying. You wouldn't buy a library if you didn't have a use for it.
• Source code - I don't have any numbers, but I believe the majority of programmers buying libraries expect source code. Examining the source code provides useful information about the library, and is an insurance policy - if something goes wrong, you always have the option of fixing it yourself, even if the vendor doesn't supply a patch. This argument is also critical for managers - it's the only way they can commit to supporting their products.
• Documentation - at the very least, a manual is required. Most customers also expect online help, integrated with the IDE. The help should include code samples, and complete application examples are highly desirable.
• Installation - an automated installation is required for any component library. Gone are the days when you could ask customers to manually install packages in the Delphi IDE.
• Licensing - at the very least, most customers expect royalty-free distribution rights, except for very high-end packages. Many developers use more than one machine, and the license should take than into account.
• Pricing - one of the trickiest issues ever. Ideally, price should be competitive, reflect the true value of the software, cover costs, return a profit, and allow future pricing flexibility when costs change. If you can figure that one out, you're smarter than anyone I know.
• Future backward compatibility - when I but a library, I want to be able to upgrade when new versions are released, but I don't want to rewrite my already-working code. For component writers, this means taking extra care with any public interfaces. A public interface is a contract between the component writer and the component user, and should be honored across product versions.
• Trial version - potential customers must be able to evaluate your product. A trial version is the best way of letting them do that. A demo application showing what can be done with your components is also extremely useful. It's also a good way to test your components in a real application. One potential problem here is installation - the full product version must take into account previous installations of the trial version.
• Distribution and protection - it should be easy for customers to buy your library, but hard to get it without paying. The trial version, however, should be as easy as possible to get.
• Development tool versions - a single component library should support most versions of the development tool for which it was written. The less versions you support, the smaller your market gets. Even if your customers don't need support for every version of the tool, it reflects badly on your product if you don't support as many versions as possible - especially since most component vendors (in the Delphi market, anyway), tend to support quite a few versions back.

In my opinion (backed by customer response), the Planners 1.0 library handles these issues pretty well. The library is obviously useful (or we wouldn't have any customers), full source code is provided, the documentation includes both a manual and integrated online help, the licensing is pretty flexible (a named used license allows a developer to install the library on multiple machines, and distribution of compiled applications and runtime libraries is royalty free), the price seems to be a pretty good match with market expectation, both a trial version and a demo are freely available from the Shorter Path site, and the full version is only available for download after purchase. The library can be downloaded as an installation program, which automatically installed the product, registers the components in all supported Delphi and C++Builder versions, registers the help files, and sets the relevant registry entries and environment variables. Planners 1.0 supports Delphi 4 through 8 and C++Builder 4 through 6. That's a total of 8 separate compilers and IDEs, all of which had to be developed and tested against.

Upgrading

Working on a new version brings up many new issues. It also raises again some of the issues you think you've already solved. In this section, I'll list the issues I've encountered with Planners, but most of these will be relevant to almost any other library.

Scope

Deciding on the scope of a new version can have many consequences, and is almost always difficult. By "scope" I mean two things: what goes into the new version in terms of fixes and features, and how is the new version packaged - as a major release, a minor upgrade, or a patch.

Many factors can affect the scope of a new release - the size of the development team, available resources, stability of the previous version, patches and upgrades of supported environments, customer feedback, and the time passed since the last release, to name a few. Scope can greatly affect other issues as well, such as installation (the requirements for installing a patch are very different from those for installing a new major release), pricing (for example, upgrades for existing users typically cost less than full versions for new users), support costs (supporting multiple versions of the product), and registrations (for example, identifying existing customers when offering upgrades).

Since the release of Planners 1.0, Borland has released Delphi 2005, which supports both Win32 and .NET development, as well as a DCU-breaking patch for Delphi 8. If we're to support Delphi 8 in the next version, we have to decide which patched version to support. Supporting Delphi 2005 adds two additional versions of the product (Win32 and VCL for .NET), bringing the total of supported versions to 10. While we could remove support for Delphi 4 and C++Builder 4 (no longer supported by Borland), we do have some customers still using these versions. Supporting VCL for .NET in both Delphi 8 and Delphi 2005 creates other problems as well, such as assembly naming and versioning issues.

Backward Compatibility

Now that we have an installed base of software products using Planners, backward compatibility becomes a very practical issue. Fortunately, the Planners architecture has proven to be extremely stable, and no breaking changes have been introduced into publicly available interfaces.

One design decision that has proven itself useful in this area when designing the first version was the decision to keep as many of the methods as possible private or protected. This allowed us to determine later on, based on customer feedback, which methods should be made public and which can remain private.

Installation

Installing an upgrade is much more difficult than a fresh installation. The installer has to gracefully handle the existence of previous versions. When installing a Delphi component library, several issues have to be taken into account. At the very least, the installer should remove registration of previous versions, since only one version of a component can be loaded by the IDE at a time.

Installing the documentation also requires special handling. Delphi 8 and Delphi 2005 use a new help system, and registering component help requires additional steps not required in previous versions.

The Planners 1.0 installer (created with Inno Setup) used a custom utility to perform the component and help registrations. Since we've designed this utility to also support un-installation, we can now use it to remove the registration without completely uninstalling previous versions. Right now, that's the path we plan to take when building the new installer. Installations are tricky, though, and we might have to come up with another solution after we've done some testing.

Documentation

Planners 1.0 included a manual (as a PDF file) and online help files. Online help was only supported on Win32-only versions of Delphi and C++Builder. At the time, the Delphi 8 component market was too small to invest in producing an additional version of the help.

A new version, however, should also provide online help for Delphi 8 and Delphi 2005. This requires migrating the current help source to a format that can be used to produce both WinHelp files (used by older versions of the IDE) and HTML Help 2 files (used by Delphi 8 and 2005). In addition, the help content must be updated to include new components, properties, methods and events. Finally, when selecting new help maintenance and generation tools and formats, we have to take into account future versions of both Planners and the development environment. Any tool we use should allow us to maintain and expand the current documentation set, rather than migrate or rewrite the content.

Costs and Pricing

Determining the direct cost of new development is fairly straightforward (determining opportunity cost is harder, but that's a different matter outside the scope of this post). The cost of an upgrade, however, can by quite difficult to determine. To the basic development cost one must add maintenance and support costs, which increase with the number of existing customers and previous versions. There are hidden costs in maintaining backward compatibility, for example, since it imposes limitations on the design of new solutions.

As a result, the cost of an upgraded version might be higher than that of a first version. Pricing, however, is less flexible for an upgrade than it is for a first version. While all considerations mentioned above when pricing the first version still apply when pricing a new version of new users, a reasonable pricing must also be determined for existing customers. In fact, upgrade pricing should probably be taken into account when pricing your first version.

Registration

There are many uses for registration, including software protection, marketing, and support offerings. The main issue involved with moving from a first version to an upgrade, though, is identifying existing customers in order to provide upgrade pricing.

Before releasing your first version, consider implementing some form of registration you can later use to provide upgrades at a reduced price. Implementing registration after the product has been released can be difficult. Planners 1.0 did not implement any registration other than that provided by our sales site, share-it!. As a result, we'll probably use e-mail to approve upgrade purchases based on sales information provided by share-it!. Fortunately, the information was sent as XML, which makes it easy to parse and store in a database which can then be used to automate most of the process.