ekmett at gmail.com
Tue Mar 2 09:33:57 UTC 2021
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
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.
> (*) 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs