GHC 9.1?

[Ben Gamari]

Richard Eisenberg <rae at richarde.dev> writes:

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210302/9d5fe00a/attachment.sig>