Hi, 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. 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?

majormajor.odd.time stamp

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. I do get why we want to embed it for release management purposes, though. Cheers, Sebastian Am Di., 2. März 2021 um 05:45 Uhr schrieb Carter Schonwald < carter.schonwald@gmail.com>:

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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

As ben says, a lot of our tools have made choices over time that make having the odd vs even convention super easy to support for compiler and library devs doing experiments with ghc builds that are based off master. No matter what, any naming scheme is a social construct for communicating with tools and humans. And I def agree that “how to interpret a ghc version number” is a useful thing to make more readily explained, any convention that changes the way cabal/library authors can experiments to suport / evaluate how features in an unreleased ghc work for them has a nontrivial engineering cost footprint. On Tue, Mar 2, 2021 at 7:26 AM Ben Gamari wrote:

Sebastian Graf writes:

...

Hi,

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.

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?

One reason is that our versioning data model (as captured by Data.Version) now only admits numeric version components. Textual tags were previously admitted but deprecated in #2496 as there is no clear ordering for such versions.

...

...

majormajor.odd.time stamp

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.

I disagree here. Personally, if I do something non-sensical I would much rather get predictable version error than be sent off on a wild-goose chase debugging ghosts. Fixing an incorrect command-line takes a few seconds; finding a bizarre runtime crash due to subtly wrong ABI may take days. This is why I generally plop any test command-line of non-trivial length into a shell script; it makes safely switching between compilers much easier.

Cheers,

- Ben

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 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs