Getting your fix: the DevExpress way

10 July 2008

We've recognized for a while that there's a minor flaw in how we disseminate fixes to our products. Sure, the primary method of doing so is to issue a new release, either minor or major, but sometimes it's necessary to post an intermediate fix in some fashion. At present this process is a little inefficient: you write to support asking for a fix, this message goes into the maw of our support system, lands on someone's desk and they then email you the required files.

Now, in actuality, not everyone wants intermediate fixes. They'll use a workaround until the next release is published and then start using the new version. However, sometimes there is no workaround and we jump into this somewhat inefficient process.

We thought about it a while and came to the conclusion that if we produce a code fix for an issue, we should make it available via the Support Center web UI for customers who need it urgently, as part of the page for that issue. We also decided that if no one actually wanted the fix that urgently, we should try and avoid doing the extra work in creating/updating the files (be they source files, DLLs, or assemblies) that a customer would need to download.

In other words, the code fix would be available by request only. The first customer that wanted the fix would trigger the extra work on our side to prepare a download package. Subsequent customers who wanted the same fix would just download the already prepared package. In essence, we should have a "load on demand" type system.

There are several types of fixes we produce

  • A small code fix for a certain file. This is of greatest benefit for our VCL customers since they are well used to modifying source code and recompiling. I would venture that our .NET customers wouldn't be that interested in this kind of fix. The extra work on our part here is not that great at all.
  • A complete set of source code files to replace the original files you've installed. Again this is of primary benefit to our VCL customers. .NET customers typically don't want to rebuild our assemblies (especially as we are not that likely to release our private signing key, sorry and all that).
  • A set of binaries, such as assemblies. This option is of primary interest to our .NET customers: they'd much prefer to download properly signed replacement assemblies that encapsulate the code fix. Of course, this is the option that requires the most amount of extra work for us, and if we can get away from doing it so much the better Smile.

So we've implemented another automated system. We're not quite sure what to call it yet -- the code name PublicCodeFix is a little boring -- but it's ready for beta testing.

The way it works under the hood is a little complex so I won't go into it here. However, how it's presented to you, our customer, is important, so let me go into that.

The UI is extremely simple: it's a button on the page for the issue in question. First of all, this button is only visible if the issue has been fixed. (To which we all go Duh!). It's also not shown if you don't have a license that is able to take advantage of the code fix. For example, if your license doesn't include source code, you won't see the button for a fix that alters your source code.

If visible, the button has three states. If the fix hasn't been generated yet, the button shows "Request Fix". If a customer clicks on the button in this state, a request is sent to support for the fix, and the button changes to "Requested". This indicates to other customers that the fix is being created and is on its way. You can click the button in this state and all that happens is that you get added to an internal list of people who want to be notified when the fix is available (the first requestor is obviously added to the same list). This list is essentially the tracking list that we already have. Finally, once we've prepared the files and the download package, we set the button to read "Available" and notify all the people tracking the issue that the fix is ready for download. In this state, you can click on the button and the fix is downloaded to your machine.

Of course, when the next version of the product is released containing the fix, the button will finally disappear for good.

We activated the PublicCodeFix application as a beta this morning so, if you see a fixed issue with this new button, you'll now know what it's all about. Needless to say, we'd love to hear your feedback about this new feature, so do please let us know using the usual support channels.

Free DevExpress Products - Get Your Copy Today

The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the DevExpress Support Center at your convenience. We'll be happy to follow-up.
No Comments

Please login or register to post comments.