What do *you* do when a maintenance release is announced?

Paul Usher's Blog
20 September 2013

 

dxAnnounce

Ok, so you just received the announcement ‘DevExpress Announcement: Maintenance Releases Now Available (v201x vol y.z)’ what do you do? 

Personally I think updates of any nature are cool; I’ve always been one for running the latest beta on any platform. Sure it’s bitten me more than once (most recently Win 8.1 RC & 8.1 RTM), but the payoff outweighs the pain. I love the chance to get to know the new feature and embrace what will be, before the masses. So the next question is, ‘how do you cope with real clients and regular updates?’, When it comes to major versions, they are pretty easy, you can run side by side versions of products and move clients or products over when you’re ready.  Minor updates can sometimes seem tedious.  I’ve worked with a large number of clients in the past running XAF, WinForms and ASP.NET, so here is a quick guide as to how we handled updates.  The first thing is to set your mindset straight, updates *are* good.  I know you only shipped a version last week, but embrace it, with a good guide you can minimize the fuss.

What machines need updating?  without going into a whole license discussion (because correct licensing IS important), the first place to start is a list of machines that need updating.  I use a hybrid setup (Mac OS X (yes Mavericks), and a virtual machine running Win 8.1 RTM. So for me it all starts with a list in OmniFocus, (although back in my solo Win days, I used MLO [MyLifeOrganised], for the same thing).   

First list the machines you need to update such as; Desktop, Laptop, Surface, Tablet. It’s important to keep all your devices running the same version.  Next make a list of all the projects you are working on, for example; [Client A], Project 1, Project 2, Project 3, [Client B], Project 1 etc..

Sometimes not all projects need to be updated straight away, but by creating the list if any bug fixes or updates is required you know exactly where you stand.  There is nothing worse than wanting to push out a quick feature and remembering you have 20mb of dependencies to deal with as well.

When it comes down to deployment, I also use the DevExpress Deployment Tool, detailed here in a knowledge base article. It is a great way to see what libraries you are using and export them to an external folder.

If you are supporting external websites, I have often found it is a good practice to pre-upload the required assemblies to a new folder on the site in preparation for the next release; for example, under the \bin folder, I would create a \bin\13.1.7 folder and upload all the necessary DLL’s ready, so when I publish the next update for the site, instead of finding all the files and uploading, they are already there. Of course my experience is dealing with really slow internet and many minutes of waiting for files to be published.

Whatever plan you undertake, there are some key aspects to maintenance releases…

  1. Stay up to date
  2. Keep a template list of dev machines to update
  3. Keep a template list of client projects to update
  4. Pre-publish files in preparation for the next version of your product
  5. Check out the ‘Whats New’ and ‘Breaking Changes’

I’d love to hear how you handle your updates, leave a comment below….

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.
Matthieu Penant
Matthieu Penant

We re-package reditributable devExpress dlls in nuget packages (specific packages, to avoid a big chunk of dlls at once) at each updates, as it is the way to go for dependencies management now. This way, it's a lot easier to use the standard tools for built automation, symbols management (with SymbolSource on aprivate server - www.symbolsource.org/Public) and deployment afterward.

20 September 2013
Nate Laff
Nate Laff

I always update right away. Though in some cases that has bit me pretty hard.

One thing that I do though, since DX is such a large part of my project, is assign the DX Version number I'm on to the Revision segment of my version number.

For example for DX 13.1.7, I have version 2.8.13170.xxx

This way when error reports are submitted I can instantly look at the version number and know which DX version they're on.

20 September 2013
Jan Doggen
Jan Doggen

'Boundary conditions:' We use Delphi VCL components. Our release cycle is generally slower than DevEx, approx. 2 large updates each year. We maintain a list of DevEx support issues, which sometimes has 1 'Needs to be fixed in next DevEx release for our app'. We have some DevEx files patched specifically for our purposes (example: the TreeBrowser extension for the Scheduler Ganttview allows only drap and drop onto groups. We rewrote that part to allow dropping on anytree node).

When a new DevEx release comes out we immediately check what's been fixed, then plan when to upgrade DevEx - which includes again importing our patches into the DevEx code (some patches may no longer be necessary). One developer tests that. We do not update every version, only when it fits into our release cycle ("If it ain't broke, don't fix it"). We are a bit conservative about updating DevEx because we have been bitten by regression bugs/new bugs. IIRC that was early in the 2012.xx series, there really was a period there where the VCL code quality decreased. That seems to have improved again.

23 September 2013
Edilson Junior
Edilson Junior

I cry, mostly :( I still didn't get an effective way to update my customers machines. For example, about two months ago we decided to update the customers with 13.1.6, since it looked very stable, but it had a bug I was not aware until couple weeks ago (since it was just a model editor issue, it took a while until I noticed it). Now I'm too small to work with 2 devexpress version and preventing error at the same time. So I'll finish my customers update and probably gonna make the next update with 13.2.xx

The problem is ME, actually, the way I do the things, and I know that. The only way DX could help would be if it has some release schedule. And possibily with a plan (updated often) with the chances I might see in the next release.

23 September 2013
Brian Maxim
Brian Maxim

Never update straight away any more. We always wait for the 2nd or 3rd minor update after the main release as it seems to contain the most major bug fixes.

It's definitely more maintainable to stay on one version and too many versions of DX installed slows down the VS IDE.

24 September 2013
ACT GOV
ACT GOV

Key issue we see with the upgrade is that there is no way to find out what is the list of outstanding fixed issues in latest available or any particular release, even there is implemented in section for each bug fix.

Other issue is breaking changes, no way to get list of that to be able filter, sort, search.

Themes upgrade is another big problem if you customize themes.

That's why after last release when we had lots of troubles we still on 10.2 and now looking to upgrade to latest version, but have to be very careful...

12 February 2014
Dave VanderWekke (Automated Wireless Environments)
Dave VanderWekke (AWE)

Currently some of our software is distributed via file copy / regasm scripts.  Whenever we get a notice of a DevExpress maintenance release we of course have a good laugh because the timing is usually just about when we finally released our software with the last DevExpress updates.  But seriously...

We read all of the release notes to see not only if there are important fixes to either bugs we've encountered, bugs we feel will affect the user experience if they occur or simply fixes to allow us to implement any items we couldn't do to bugs.  We also go through the breaking changes list to ensure we don't break anything.

We then will create a copy of our project(s) detached from source control and perform the upgrade several times to ensure the process works correctly.  We then go through a shakeout test to ensure nothing is broken and then we will schedule our release. Because we are in the process of upgrading several products we are very much in flux right now, but we plan to create cleanup scripts to remove all the old DevExpress DLLs that were distributed with each upgrade.  In some cases we still have version 9.x.x of DevExpress being used by some products while others are up to date running 13.2.7.  We have evaluated 13.2.8 because we recently released out 13.2.7 upgrade and have decided to hold off upgrades until the large May 2014 release of DevExpress as our next major jump.

19 March 2014

Please login or register to post comments.