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 <loneti...@gmail.com> 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 <ekm...@gmail.com > <mailto:ekm...@gmail.com>> 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 <r...@richarde.dev > <mailto: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 <mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs> > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <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
