<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2021, at 10:36 AM, Phyx <<a href="mailto:lonetiger@gmail.com" class="">lonetiger@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">I am also against not using the odd/even versioning scheme. <div dir="auto" class=""><br class=""></div><div dir="auto" class="">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. </div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">If GHC were to invent its own thing, especially if it's alpha numeric this would be a huge pain for no real benefit. </div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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. </div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Kind regards, </div><div dir="auto" class="">Tamar <br class=""><br class=""><div data-smartmail="gmail_signature" dir="auto" class="">Sent from my Mobile</div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 2, 2021, 09:34 Edward Kmett <<a href="mailto:ekmett@gmail.com" class="">ekmett@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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</div><div class=""><br class=""></div><div class="">-Edward</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 1, 2021 at 8:30 PM Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank" rel="noreferrer" class="">rae@richarde.dev</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi devs,<br class="">
<br class="">
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?"<br class="">
<br class="">
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.<br class="">
<br class="">
I don't feel strongly about this, at all -- just asking a question that maybe no one has asked in a long time.<br class="">
<br class="">
Richard<br class="">
<br class="">
(*) 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.<br class="">
_______________________________________________<br class="">
ghc-devs mailing list<br class="">
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer" class="">ghc-devs@haskell.org</a><br class="">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br class="">
</blockquote></div>
_______________________________________________<br class="">
ghc-devs mailing list<br class="">
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer" class="">ghc-devs@haskell.org</a><br class="">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>