GHC 9.1?

[Carter Schonwald]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210301/bea44db8/attachment.html>