Re: GHC 9.1?

[Richard Eisenberg]

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 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 
> 

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

Re: GHC 9.1?

[Phyx]

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

Re: GHC 9.1?

[Carter Schonwald]

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

Re: GHC 9.1?

[Ben Gamari]

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


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 9.1?

[Ben Gamari]

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 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.
>

At this point there isn't any reason strong reason for either design.
However, it also never really occurred to me that our convention could
be confusing.

I do believe that there is value in having a clear versioning scheme for
non-released compilers. However, I can't think of anything that would
break if we, for instance, used 9.0.99 instead of 9.1 (other than being
a bit ugly)

The strongest argument I can put forth for the status quo is that it is
eases adapting GHC API users prior to GHC release. Specifically,
head.hackage maintains the policy that any patch be buildable with both
current GHC major release and GHC's `master` branch. In order to achieve
this, it is often necessary to write CPP guards that condition on the
`ghc` library version. The idiomatic way to accomplish this is Cabal's
MIN_VERSION_ghc macro, which only allows you to predicate on the two
most-significant version numbers (since the PVP dictates that breaking
changes should change the second version component, at least). Using
MIN_VERSION_ghc would become impossible in a three-component versioning
scheme.

To work around this, we would either have to use a hack like
__GLASGOW_HASKELL_FULL_VERISON__ or drop the two version buildability
requirement on head.hackage patches. I would really rather not do the
latter as it would severely hamper the usability of the patch-set for
differential performance testing. The former seems unfortunate since it
means more work to turn a head.hackage patch into something upstremable.

Now since I've written this down, I would place my vote under
retaining even-odd numbering. Not only does this have historical
precedent in its favor, but it also has at least one clear technical
advantage.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 9.1?

[Edward Kmett]

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

Re: GHC 9.1?

[Sebastian Graf]

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

Re: GHC 9.1?

[Carter Schonwald]

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