There are 2 numbers - the build number (ICMS_VERSION_BUILD), which should increase with every release and the dbversion (ICMS_SYSTEM_DBVERSION), which should only increase when there are db updates to apply (or other scripts that are required to run for the update, as when we were deleting some vulnerable files).

The way the version checker works, it relies on 2 things - the build number in include/version.php and the first value in the guid in xml file.

      For full changelog - visit:
      Tue, 3 May 2011 21:32:00 -0400

The first value is the build number, the second is the release type (1 = alpha, 2 = beta, 3 = RC, 10 = final). When the version checker runs, it grabs the xml file and parses it. Then, it compares the current build number on the site with the one found in the xml file. If the build number in the xml file is higher, then the site is not the latest version. Then, it also checks to see if the user would be updating from a final version to an experimental version (alpha, beta or RC) and provides the appropriate message.

The Challenge

The challenge with this is 2 different release cycles can overlap, as they have done in the 1.3 release cycle and the 1.2.4/1.2.5 release cycles. We had these events -
1.2.4 Final
1.3 Alpha
(Repackaged 1.2.4 with the proper content module)
1.3 Beta
1.2.5 Final
1.3 Beta 2

Each time, the build number needs to be updated, so when using the version checker the proper information is provided. We also don't want to take people backwards, from 1.3 Beta to 1.2.5 Final, we only want them to follow the path they're on. The version checker is safe as long as we only update the xml file when we release a final version. If we want to use the version checker with experimental versions, too, we'll need to extend our current system to allow for these odd paths. It really should be rare we release another final version during a new release cycle.


ICMS_SYSTEM_DBVERSION is not used by the version checker - it is only used when updating the system module. When the system module is updated, it gets the current dbversion from the database (modules table, dbversion field for the system module) and compares it to the value in include/version.php. Then, as system/include/update.php is run, it applies the proper updates to the database.

The challenge with this is sometimes there are reasons to apply updates that are not database updates. These have been exceptions, but we may run into more times when we need to do this, like when we remove the class/ and kernel/ folders from the core.

Last modified on 2014/3/5 by Anonymous
The comments are owned by the poster. We aren't responsible for their content.