If you're wondering whether or not you should upgrade, these notes may help you make your decision.

from 4.10 to 4.20 (and future)

• Upgrade support is provided solely to GridBuilder users via the supplied automatic upgrade templates.  Everybody else: get out your code editor and compare the config files   

from v4.0 to 4.10

• If you are a registered GridBuilder user, just download the latest version and run the Upgrader to upgrade your existing database.  Then just re-generate each grid you want to upgrade.
• To upgrade the grids manually, simply add the RowsToShow parameter in your config file, and set the value to the number of rows you want to show on each template by default.

from v3.51 to 4.0

• GM4 offers significant new functionality, coupled to new config parameters.  The config files have changed to a fairly significant degree.  Particularly, the custom code area has been completely reworked.  Upgrading is strongly recommended; especially if you can benefit from centralizing your config file creation with GridBuilder.
• UPGRADE PROCEDURE:
1. Replace your existing GridMonger file set with the latest version.
2. Redo all of your config files (there are many similarities so you'll be able to paste in most of your old settings).  The use of GridBuilder will make this process a lot easier; especially when the next upgrade comes along and GridBuilder upgrades all of your config files automatically for you.

from version 3.50 to 3.51

• This is a bugfix release and you should upgrade if using v3.50.
• UPGRADE PROCEDURE:
1. Replace your existing GridMonger file set with the latest version.
2. No alteration of config files is necessary.  See the supplied Application.cfm for the settings necessary to enable emailed error messages.  Add this code where appropriate in your application. 

• Code rewrites in v3.50 improve the code's modularity, and arguably improve its readability, but no additional functionality results from this (any improvements in execution time are swallowed up by database performance).  Unless you need one of the bugfixes, or would benefit from emailed rather than onscreen errors (which realistically everyone should strongly consider) then an upgrade is unnecessary.
• UPGRADE PROCEDURE:
1. Replace your existing GridMonger file set with the latest version.
2. No alteration of config files is necessary.  See the supplied Application.cfm for the settings necessary to enable emailed error messages.  Add this code where appropriate in your application. 

• 3.40 is not a bug-fix release, with one obscure exception.  If you want any of the added features in 3.40, then upgrade.  Otherwise 3.31 is fully functional.
• UPGRADE PROCEDURE: 
1. Replace your existing GridMonger file set with the latest version.
2. No alteration of your config file is required if you are using v3.20+.
3. See inlinedemo3.cfm for a config file that displayes the new edit mode settings and uses hidden inputs.  Retrofit your existing config files as desired.

• If you use ...
  v3.30: YES.  3.30 has a nasty bug (inserted records in *some* views are null)
  v3.20:  maybe. 
  Earlier versions: YES if you want the features.
   
• v3.31 also fixes a benign error, unreported but discovered during our own internal use, that prevents proper display during the 'Are You Sure?' deletion confirmation:  The record data would not display on the confirmation screen.  Expanded view modes were unaffected by this error, which dates back version 3.20.
    
• UPGRADE PROCEDURE:  Replace your existing GridMonger file set with the latest version.  There is no need to alter your config files.

• v3.30 is a minor revision that is unnecessary except for MS Access users who want to use MS Access date format fields.  GM3.3's ability to bypass cfqueryparam and use 'raw' inserts and updates works around Access' issues with the use of cfqueryparam on its date fields.  Note that the use of cfqueryparam is strongly recommended, and the use of MS Access is likewise discouraged.
   
• One user reported text case issues with some variable lists, and the use of ListFindNoCase throughout the codebase eliminates any further potential for problems.  Since this issue has never been seen in extensive use internally, and was reported only once, unless you've experienced the problem there is no reason to upgrade over this issue.
   
• UPGRADE PROCEDURE: 
1. At your option, revise your config files to account for the new options.  This is strictly an issue of documentation and has no bearing on performance or capabilities.  To upgrade to the latest code comments, copy Lines 91-96 from inlinedemo.cfm and paste them into the corresponding spot in your own config templates.
    
2. Replace your existing GridMonger file set with the latest version.

• v3.20 is a minor revision, unless you want to take fuller advantage of one of the Expanded View modes, which were significantly revised.  Also, users who experienced problems with cfsqltype support should take advantage of the now-complete support for all cfsqltype parameters.
   
• UPGRADE PROCEDURE:

1. Revise your config template to take into account these new parameters (Default is shown; all are found in the Custom External Item Area):

variables.Custom01Target="_self";
variables.Custom02Target="_self";
variables.Custom03Target="_self";

2. Replace your existing GridMonger file set with the latest version.