Richard Eisenberg
Hi devs,
I understand that GHC uses the same version numbering system as the Linux kernel did until 2003(*), using odd numbers for unstable "releases" and even ones for stable ones. I have seen this become a point of confusion, as in: "Quick Look just missed the cutoff for GHC 9.0, so it will be out in GHC 9.2" "Um, what about 9.1?"
Is there a reason to keep this practice? Linux moved away from it 18 years ago and seems to have thrived despite. Giving this convention up on a new first-number change (the change from 8 to 9) seems like a good time.
I don't feel strongly about this, at all -- just asking a question that maybe no one has asked in a long time.
At this point there isn't any reason strong reason for either design. However, it also never really occurred to me that our convention could be confusing. I do believe that there is value in having a clear versioning scheme for non-released compilers. However, I can't think of anything that would break if we, for instance, used 9.0.99 instead of 9.1 (other than being a bit ugly) The strongest argument I can put forth for the status quo is that it is eases adapting GHC API users prior to GHC release. Specifically, head.hackage maintains the policy that any patch be buildable with both current GHC major release and GHC's `master` branch. In order to achieve this, it is often necessary to write CPP guards that condition on the `ghc` library version. The idiomatic way to accomplish this is Cabal's MIN_VERSION_ghc macro, which only allows you to predicate on the two most-significant version numbers (since the PVP dictates that breaking changes should change the second version component, at least). Using MIN_VERSION_ghc would become impossible in a three-component versioning scheme. To work around this, we would either have to use a hack like __GLASGOW_HASKELL_FULL_VERISON__ or drop the two version buildability requirement on head.hackage patches. I would really rather not do the latter as it would severely hamper the usability of the patch-set for differential performance testing. The former seems unfortunate since it means more work to turn a head.hackage patch into something upstremable. Now since I've written this down, I would place my vote under retaining even-odd numbering. Not only does this have historical precedent in its favor, but it also has at least one clear technical advantage. Cheers, - Ben