GHC releases and versions

[Iavor Diatchki]

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 <sylvain at haskus.fr> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210528/26140f27/attachment.html>