Javran Cheng writes:
> Hi all,
>
Hi Javran,
> I'm a newcomer (not entirely new as I did have some contribution few years
> back but the workflow seems to have changed a lot) and is working on
> https://gitlab.haskell.org/ghc/ghc/-/issues/15932.
> I'm looking for some (informal) mentorship on
Ben Gamari writes:
> tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss,
>especially if you have something you would like merged for 9.2.1.
>
> Hello all,
>
Hi all,
With the planned fork deadline looming, I thought now would be a good
time for a bit of a status update.
Hi all,
I'm a newcomer (not entirely new as I did have some contribution few years
back but the workflow seems to have changed a lot) and is working on
https://gitlab.haskell.org/ghc/ghc/-/issues/15932.
I'm looking for some (informal) mentorship on that issue - I think I know what
the problem is
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
