GHC 9.1?

[Phyx]

I am also against not using the odd/even versioning scheme.

My objections are similar to what Edward mentioned in that adding "junks"
at the end of the build number is problematic for packagers of the
toolchain where the packaging has its own way to mark something
pre-release.

If GHC were to invent its own thing, especially if it's alpha numeric this
would be a huge pain for no real benefit.

A beginner can quickly see on Wikipedia or other places that the compiler
only does even numbered releases, but the changes has a lot of wide
spreading implications.

Kind regards,
Tamar

Sent from my Mobile

On Tue, Mar 2, 2021, 09:34 Edward Kmett <ekmett at gmail.com> wrote:

> In the past I've gained non-zero utility from having the spacer there to
> allow me to push patches in to allow HEAD builds while features are still
> in flux. Some of those in flux changes -- to my mild chagrin -- made it out
> to hackage, but were handled robustly because I wasn't claiming in the code
> that it worked on the next major release of GHC. Admittedly this was in the
> before-times, when it was much harder to vendor specific versions of
> packages for testing. Now with stack.yaml and cabal.project addressing that
> detail it is much reduced concern.
>
> That isn't to say there is zero cost to losing every other version number,
> but if we want to allow GHC versions and PVP versions to mentally "fit in
> the same type" the current practice has the benefit that it doesn't require
> us either doing something like bolting tags back into Data.Version to
> handle the "x.y.nightly" or forcing everyone to move to the real next
> release the moment the new compiler ships with a bunch of a jump, or
> generally forcing more string-processing nonsense into build systems. Right
> now version numbers go up and you can use some numerical shenanigans to
> approximate them with a single integer for easy ifdefs.
>
> I'm ever so slightly against recoloring the bikeshed on the way we manage
> the GHC  version number, just because I know my tooling is robust around
> what we have, and I don't see marked improvement in the status quo being
> gained, while I do foresee a bit of complication around the consumption of
> ghc as a tool if we change
>
> -Edward
>
> On Mon, Mar 1, 2021 at 8: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/1ed3c521/attachment.html>