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