1.3. GHC version numbering policy

As of GHC version 6.0, we have adopted the following policy for numbering GHC versions:

Stable Releases

These are numbered x.y.z, where y is even, and z is the patchlevel number (the trailing .z can be omitted if z is zero). Patchlevels are bug-fix releases only, and never change the programmer interface to any system-supplied code. However, if you install a new patchlevel over an old one you will need to recompile any code that was compiled against the old libraries.

The value of __GLASGOW_HASKELL__ (see Section 4.10.3) for a major release x.y.z is the integer xyy (if y is a single digit, then a leading zero is added, so for example in version 6.2 of GHC, __GLASGOW_HASKELL__==602).

Snapshots/unstable releases

We may make snapshot releases of the current development sources from time to time, and the current sources are always available via the CVS repository (see the GHC web site for details).

Snapshot releases are named x.y.YYYYMMDD where y is odd, and YYYYMMDD is the date of the sources from which the snapshot was built. In theory, you can check out the exact same sources from the CVS repository using this date.

The value of __GLASGOW_HASKELL__ for a snapshot release is the integer xyy. You should never write any conditional code which tests for this value, however: since interfaces change on a day-to-day basis, and we don't have finer granularity in the values of __GLASGOW_HASKELL__, you should only conditionally compile using predicates which test whether __GLASGOW_HASKELL__ is equal to, later than, or earlier than a given major release.

The version number of your copy of GHC can be found by invoking ghc with the ––version flag (see Section 4.5).