<div dir="ltr"><div>Hi,</div><div><br></div><div>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.<br></div><div><br></div><div>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?<br></div><div><br></div><div>> majormajor.odd.time stamp</div><div><br></div><div>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.</div><div>I do get why we want to embed it for release management purposes, though.</div><div><br></div><div>Cheers,</div><div>Sebastian<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 2. März 2021 um 05:45 Uhr schrieb Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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? </div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Otoh. It’s all a social construct. So any approach that helps all relevant communities is always welcome.  Though even numbers are nice ;)</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 1, 2021 at 11:30 PM Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>> wrote:<br></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>
<br>
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>
<br>
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>
<br>
I don't feel strongly about this, at all -- just asking a question that maybe no one has asked in a long time.<br>
<br>
Richard<br>
<br>
(*) 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>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>