Version Numbers

Helios <= 1.4

Version numbers are 1.4.YEAR.BUILD.

As a result, upgrades do not work for builds from the same year Microsoft MSI technology ignores the fourth number for version comparisons. So all builds from the same year are considered separate productIds that cannot be upgraded in spite of having the same upgradeId.

Helios 1.6

Version numbers are 1.6.BUILD.REVISION, as intended by Microsoft and required by MSI to function correctly. There are additional rules for assigning these numbers for Helios:

• Never ship the same 1.6.BUILD combination twice. Increment BUILD for at least every release candidate.
• BUILD must be at least 3000 for a released build to avoid confusion with 1.4 numbers.
• REVISION doesn't do anything in the installer, so you can't use it to differentiate releases. However, you can increment it when you are repeating a build because you found problems with it before you gave it to anyone else.
• Development prototypes sent out privately for testing must have a build number between 1000 and 1999 inclusive.
• If a build has this type of build number, then a few things in Helios change:
  • The default Documents folder is "HeliosDev" instead of "Helios" and it can only be overridden with "-devdocuments" instead of "-documents" command line parameter.
  • The build will stop working 30 days after the date in Helios\TimeStamp.g.cs. To update this file, save the file "Helios\TimeStamp.tt" in Visual Studio and it will rewrite the time stamp.
• All Development Prototypes should be 1.6.1000.* unless you intend for your testers to use upgrade from build to build.
  • You can use REVISION (which does nothing) to mark multiple 1.6.1000.1, 1.6.1000.2, etc. test builds that all have to completely uninstall and reinstall, so you don't have to worry about installer issues while testing functionality.
  • Alternatively, you can use 1.6.1000.*, 1.6.1001.*, etc. to allow these builds to upgrade when installed by your testers.