GHC 9.1?

[Carter Schonwald]

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 <ben at smart-cactus.org> wrote:

> Sebastian Graf <sgraf1337 at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210302/b1e2f3f2/attachment.html>