ANNOUNCE: GHC 6.6 Second Release Candidate

Simon Marlow simonmarhaskell at
Mon Oct 9 07:01:54 EDT 2006

Brian Smith wrote:
> On 10/8/06, *Ross Paterson* <ross at 
> <mailto:ross at>> wrote:
>     On Sun, Oct 08, 2006 at 05:30:25PM -0500, Brian Smith wrote:
>      > I see that it is documented in later versions. But, I don't see how
>      > that mechanism would help in this situation.
>     You still have to bump the version number immediately before you
>     release.
>     You can bump it again immediately after you release (e.g. if you're
>     using
>     Linux-style odd/even version numbering), but you don't have to, because
>     snapshot source distributions will have version numbers like
>     2.0.20061008
>     -- intermediate between 2.0 and 2.1, but with a date for bug tracking.
> Isn't that assuming that everybody gets packages from source 
> distributions? In reality, nobody is making snapshot distributions--if 
> somebody has a non-release version, they most likely got it directly 
> from the repository and not from a source distribution.

Ian is going to bump the version of all packages for 6.6.

I agree that we should also establish a versioning convention.  Ross's 
suggestion is to use 'sdist --snapshot' to ensure that the version number of a 
post-release version is greater than the release version number.  I think this 
will be inconvenient: if I need to install a new version of a package to satisfy 
some dependency and the package isn't officially released yet, I have to get it 
from darcs, 'setup sdist --snapshot', and build from the snapshot rather than 
just building from darcs.

The even/odd versioning scheme works well in these situations.  However, we 
don't necessarily need to be that strict: just having the convention that the 
version is bumped for a release and bumped immediately after the release is good 
enough.  Development versions could additionally be tagged with '-devel' or '-head'.

The "extra" packages will be decoupled from GHC, so I expect in the future we'll 
just use tarballs or stable repositories for these, if we ship them at all.  For 
the core packages we'll probably still need our own repositories, and we'll 
continue to branch them for each major GHC release, but we'll coordinate with 
everyone else (eg. Hugs or standalone releases) for version numbering of these 


More information about the Glasgow-haskell-users mailing list