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 wrote:
>
> I am also against not using the odd/even versioning scheme.
>
> My objections are similar
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
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
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
Richard Eisenberg writes:
> 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
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
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
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
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
