GHC 9.1?

[Richard Eisenberg]

Thanks for the input, all. I'm now convinced that retaining the current odd/even scheme has concrete benefits and am happy to continue doing it.

Richard

> On Mar 2, 2021, at 10:36 AM, Phyx <lonetiger at gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <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/3f1fda69/attachment.html>