GHC 9.1?

[Sebastian Graf]

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?

> 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 do get why we want to embed it for release management purposes, though.

Cheers,
Sebastian

Am Di., 2. März 2021 um 05:45 Uhr schrieb Carter Schonwald <
carter.schonwald at gmail.com>:

> It makes determining if a ghc build was a dev build vs a tagged release
> much easier.  Odd == I’m using a dev build because it reports a version
> like majormajor.odd.time stamp right ? — we still donthat with dev /master
> right?
>
> At some level any versioning notation is a social convention, and this one
> does have a good advantage of making dev builds apparent while letting
> things like hackage head have coherent versioning for treating these
> releases sanely?
>
> Otoh. It’s all a social construct. So any approach that helps all relevant
> communities is always welcome.  Though even numbers are nice ;)
>
> On Mon, Mar 1, 2021 at 11:30 PM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>> 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.
>>
>> Richard
>>
>> (*) I actually didn't know that Linux stopped doing this until writing
>> this email, wondering why we needed to tie ourselves to Linux. I
>> coincidentally stopped using Linux full-time (and thus administering my own
>> installation) in 2003, when I graduated from university.
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210302/a210c112/attachment.html>