<div dir="ltr">Hello,<div><br></div><div>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:</div><div><br></div><div>A.B</div><div><br></div><div>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.</div><div><br></div><div>Just my 2c,</div><div>-Iavor</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 28, 2021 at 7:49 AM Sylvain Henry <<a href="mailto:sylvain@haskus.fr">sylvain@haskus.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi devs,<br>
<br>
We currently have 4 branches of GHC in flight: 8.10, 9.0, 9.2 and HEAD<br>
<br>
Latest releases:<br>
- 8.10.4: 2021/02/06<br>
- 9.0.1: 2021/02/04<br>
- 9.2.1-alpha2: 2021/04/23<br>
<br>
Considering:<br>
<br>
1) 8.10 branch should be stable but a lot of stuff has been merged for <br>
8.10.5. To the point that 8.10.5 should probably be a "major release in <br>
the 8.10 series".<br>
<br>
2) 9.0.1 is the latest major release but it shouldn't be used before <br>
9.0.2 is released because of bugs and regressions (9.0.2 branch contains <br>
a fix for a critical bug in 9.0.1 [1] since March).<br>
<br>
3) We might release 9.2.1 and 9.0.2 approximately at the same time which <br>
will be quite confusing for users ("9.0.2 in the 9.0 series and 9.2.1 in <br>
the 9.2 series").<br>
<br>
4) The first major number is meaningless.<br>
<br>
Proposition:<br>
<br>
Switch to A.B.C[.D] version scheme where:<br>
- A: major release ("series")<br>
- B: major release in the A series if B>0 and C=0; beta release if B=0<br>
- C: bugfix release for A.B (if C>0) or beta release number (if B=0)<br>
- D: date when building in tree, not for releases<br>
<br>
It might be clearer exposed like this:<br>
<br>
showVersion = \case<br>
[a,b,c,d] -> "Dev version of " ++ showVersion [a,b,c] ++ " built on " <br>
++ show d<br>
[a,0,c] -> "beta " ++ show c ++ " in series " ++ show a<br>
[a,b,0] -> "Major release " ++ show [a,b] ++ " in series " ++ show a<br>
[a,b,c] -> "Bugfix release " ++ show c ++ " for " ++ show [a,b]<br>
_ -> undefined<br>
<br>
> showVersion [9,0,1,20211028]<br>
"Dev version of beta 1 in series 9 built on 20211028"<br>
> showVersion [9,0,1]<br>
"beta 1 in series 9"<br>
> showVersion [9,0,2]<br>
"beta 2 in series 9"<br>
> showVersion [9,1,0]<br>
"Major release [9,1] in series 9"<br>
> showVersion [9,1,1]<br>
"Bugfix release 1 for [9,1]"<br>
> showVersion [9,2,0]<br>
"Major release [9,2] in series 9"<br>
> showVersion [10,1,0]<br>
"Major release [10,1] in series 10"<br>
<br>
Effects:<br>
<br>
1) We could use C for bugfix versions which are to be released much <br>
faster than major versions.<br>
2) B would be used for the old series we maintain. We backport a lot <br>
more stuff than before in older releases it seems, so it would be more <br>
PVP compliant to bump a major version number.<br>
3) A would be used for the usual 6-month major releases.<br>
4) We could make major releases in the 8 series (e.g. 8.10.5 could be <br>
released as 8.11.0)<br>
5) We could advertise 9.0.1 as a beta (as everyone seems to consider .1 <br>
releases)<br>
6) 9.2.1 final could be released either as 9.3 (next major in the 9 <br>
series if we just forget about 9.0.* and 9.2.*) or as 10.1.0 (first <br>
major in the 10 series).<br>
7) No difference anymore between even/odd version numbers (for reference <br>
the current scheme is explained in [2])<br>
<br>
Any thoughts?<br>
Sylvain<br>
<br>
<br>
[1] <a href="https://mail.haskell.org/pipermail/haskell-cafe/2021-March/133540.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/haskell-cafe/2021-March/133540.html</a><br>
[2] <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/working-conventions/releases" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/wikis/working-conventions/releases</a><br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>