Hello, I never understood what the first version number in GHC is for (the one you refer to as "series", and that recently changed from 8 to 9). To me it makes more sense to have 2 numbers for proper releases and 2 numbers+date (or git hash) for development. So the format would be: A.B where A is incremented for each release (roughly 6 months apart) and B is incremented for different variations of each release. B resets back to 0 at each 6 month release cycle, so the very first release candidate would be `A.0` with others being `A.1`, `A.2` etc, until the actual release seattles at `A.R`, which would last for about 6 months when we'd go to `A+1`. If we need a bug fix release before the 6 month period has expired, we just bump `B` to `A.(R+1)`, etc. Just my 2c, -Iavor On Fri, May 28, 2021 at 7:49 AM Sylvain Henry wrote:

Hi devs,

We currently have 4 branches of GHC in flight: 8.10, 9.0, 9.2 and HEAD

Latest releases: - 8.10.4: 2021/02/06 - 9.0.1: 2021/02/04 - 9.2.1-alpha2: 2021/04/23

Considering:

1) 8.10 branch should be stable but a lot of stuff has been merged for 8.10.5. To the point that 8.10.5 should probably be a "major release in the 8.10 series".

2) 9.0.1 is the latest major release but it shouldn't be used before 9.0.2 is released because of bugs and regressions (9.0.2 branch contains a fix for a critical bug in 9.0.1 [1] since March).

3) We might release 9.2.1 and 9.0.2 approximately at the same time which will be quite confusing for users ("9.0.2 in the 9.0 series and 9.2.1 in the 9.2 series").

4) The first major number is meaningless.

Proposition:

Switch to A.B.C[.D] version scheme where: - A: major release ("series") - B: major release in the A series if B>0 and C=0; beta release if B=0 - C: bugfix release for A.B (if C>0) or beta release number (if B=0) - D: date when building in tree, not for releases

It might be clearer exposed like this:

showVersion = \case [a,b,c,d] -> "Dev version of " ++ showVersion [a,b,c] ++ " built on " ++ show d [a,0,c] -> "beta " ++ show c ++ " in series " ++ show a [a,b,0] -> "Major release " ++ show [a,b] ++ " in series " ++ show a [a,b,c] -> "Bugfix release " ++ show c ++ " for " ++ show [a,b] _ -> undefined

...

showVersion [9,0,1,20211028] "Dev version of beta 1 in series 9 built on 20211028" showVersion [9,0,1] "beta 1 in series 9" showVersion [9,0,2] "beta 2 in series 9" showVersion [9,1,0] "Major release [9,1] in series 9" showVersion [9,1,1] "Bugfix release 1 for [9,1]" showVersion [9,2,0] "Major release [9,2] in series 9" showVersion [10,1,0] "Major release [10,1] in series 10"

Effects:

1) We could use C for bugfix versions which are to be released much faster than major versions. 2) B would be used for the old series we maintain. We backport a lot more stuff than before in older releases it seems, so it would be more PVP compliant to bump a major version number. 3) A would be used for the usual 6-month major releases. 4) We could make major releases in the 8 series (e.g. 8.10.5 could be released as 8.11.0) 5) We could advertise 9.0.1 as a beta (as everyone seems to consider .1 releases) 6) 9.2.1 final could be released either as 9.3 (next major in the 9 series if we just forget about 9.0.* and 9.2.*) or as 10.1.0 (first major in the 10 series). 7) No difference anymore between even/odd version numbers (for reference the current scheme is explained in [2])

Any thoughts? Sylvain

[1] https://mail.haskell.org/pipermail/haskell-cafe/2021-March/133540.html [2] https://gitlab.haskell.org/ghc/ghc/-/wikis/working-conventions/releases

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