Re: GHC 9.1?

As ben says, a lot of our tools have made choices over time that make having the odd vs even convention super easy to support for compiler and library devs doing experiments with ghc builds that are based off master. No matter what, any naming scheme is a social construct for communicating with tools and humans. And I def agree that “how to interpret a ghc version number” is a useful thing to make more readily explained, any convention that changes the way cabal/library authors can experiments to suport / evaluate how features in an unreleased ghc work for them has a nontrivial engineering cost footprint. On Tue, Mar 2, 2021 at 7:26 AM Ben Gamari wrote:

Sebastian Graf writes:

...

Hi,

I generally would like +0.1 steps, but mostly because it causes less head-scratching to everyone new to Haskell. Basically the same argument as Richard says.

I can't comment on how far head.hackage (or any tool relies) on odd version numbers, I certainly never have. Given that it's all overlays (over which we have complete control), does it really matter anyway? When would we say <=9.1 rather than <=9.2? Shouldn't 9.1 at one point become binary compatible with 9.2, as if it really was "9.2.-1" (according to the PVP, 9.2.0 is actually > 9.2, so that won't work)? I think there are multiple ways in which we could avoid using 9.1 as the namespace for "somewhere between 9.0 and 9.2 exclusively". We have alpha releases, so why don't we name it 9.1.nightly?

One reason is that our versioning data model (as captured by Data.Version) now only admits numeric version components. Textual tags were previously admitted but deprecated in #2496 as there is no clear ordering for such versions.

...

...

majormajor.odd.time stamp

TBH, I found the fact that the *configure* date (I think?) is embedded in the version rather annoying. I sometimes have two checkouts configured at different dates but branching off from the same base commit, so I'm pretty sure that interface files are compatible. Yet when I try to run one compiler on the package database of the other (because I might have copied a compiler invocation from stdout that contained an absolute path), I get an error due to the interface file version mismatch. I'd rather have a crash or undefined behavior than a check based on the configure date, especially since I'm just debugging anyway.

I disagree here. Personally, if I do something non-sensical I would much rather get predictable version error than be sent off on a wild-goose chase debugging ghosts. Fixing an incorrect command-line takes a few seconds; finding a bizarre runtime crash due to subtly wrong ABI may take days. This is why I generally plop any test command-line of non-trivial length into a shell script; it makes safely switching between compilers much easier.

Cheers,

- Ben