|
2 | 2 |
|
3 | 3 | # Releases
|
4 | 4 |
|
5 |
| -!!! todo "To do - Simplify the branch or version structure" |
| 5 | +## Branches |
6 | 6 |
|
7 |
| - Just release from the `master` branch (but keep the `stable` branch |
8 |
| - tracking the latest stable release plus updates to documentation). |
| 7 | +* The `release` branch is intended to preserve the most recent release |
| 8 | + (including, if applicable, Hackage-only dependency compatibility patch |
| 9 | + releases). |
9 | 10 |
|
10 |
| -## Version scheme |
| 11 | +* The `stable` branch is intended to be a copy of the `release` branch together |
| 12 | + with any subsequent commits that (only) revise the documentation for the most |
| 13 | + recent release. That documentation is presented at <https://haskellstack.org>. |
11 | 14 |
|
12 |
| -A Stack package or executable may have a version with three or four components: |
13 |
| -`X.Y.Z` or `X.Y.Z.A`. |
| 15 | +* The `master` branch is the current development branch. It is intended that a |
| 16 | + working version of Stack can be built from the branch. The release process |
| 17 | + begins with a copy of the branch. |
14 | 18 |
|
15 |
| -### Development or stable versions |
16 |
| - |
17 |
| -* Versions with an _even_ `Y` component are development versions (the `master` |
18 |
| - branch) |
19 |
| - |
20 |
| -* Versions with an _odd_ `Y` component are stable versions (the `stable` branch, |
21 |
| - or in a `rc/vX.Y` release candidate branch for not-yet-released versions) |
22 |
| - |
23 |
| -### Unreleased or released versions |
24 |
| - |
25 |
| -* Versions with an _even_ `Z` component are unreleased versions (including |
26 |
| - release candidates) |
27 |
| - |
28 |
| -* Versions with an _odd_ `Z` component are released versions |
29 |
| - |
30 |
| -* Except for the `release` branch (which matches exactly the most recent |
31 |
| - release), all branches must have an even `Z` component |
32 |
| - |
33 |
| -* Branches other than `stable`, `release`, and a `rc/vX.Y` release candidate |
34 |
| - will always have a `0` `Z` component |
35 |
| - |
36 |
| -### Use of a fourth component |
37 |
| - |
38 |
| -* Release candidate binaries will be released with an odd `A` component |
39 |
| - |
40 |
| -* Hackage-only dependency compatibility patch releases add a `A` component |
41 |
| - (e.g. `v2.5.1.1`, in the `release` branch) |
42 |
| - |
43 |
| -* Pre-release unstable binaries will be released with the date as the `A` |
44 |
| - component (e.g. `3.6.0.20241228`) |
45 |
| - |
46 |
| -Examples: |
47 |
| - |
48 |
| -* `3.5.0.0`: `v3.5.x` series pre-release branch (`rc/v3.5` branch) |
49 |
| - |
50 |
| -* `3.5.0.1`: first release candidate for first release of `v3.5.x` series |
51 |
| - (`rc/v3.5` branch) |
52 |
| - |
53 |
| -* `3.5.0.2`: continuing development on pre-release branch |
54 |
| - |
55 |
| -* `3.5.0.3`: second release candidate for first release of `v3.5.x` series |
56 |
| - (`rc/v3.5` branch) |
57 |
| - |
58 |
| -* `3.5.1`: first release of the `3.5.x` series (`release` branch) |
59 |
| - |
60 |
| -* `3.5.2`: development for second release of `3.5.x` series |
61 |
| - (`stable` branch) |
62 |
| - |
63 |
| -* `3.5.2.1`: first release candidate for second release of `3.5.x` series |
64 |
| - (`rc/v3.5` branch) |
65 |
| - |
66 |
| -* `3.5.3`: second release of `3.5.x` series (`release` branch) |
67 |
| - |
68 |
| -* `3.5.3.1`: first Hackage-only patch of `3.5.3` (`release` branch) |
69 |
| - |
70 |
| -* `3.5.3.2`: second Hackage-only patch of `3.5.3` (`release` branch) |
71 |
| - |
72 |
| -* `3.6.0`: unstable development code (`master` branch) |
73 |
| - |
74 |
| -* `3.6.0.20241228`: pre-release snapshot of unstable version (`master` branch) |
| 19 | +* A `rc/vX.Y` branch (named after a release in the Stack X.Y.* series) is |
| 20 | + intended to be for release candidates and final releases. It begins as a copy |
| 21 | + of the `master` branch. |
75 | 22 |
|
76 | 23 | ## Pre-release checks
|
77 | 24 |
|
78 |
| -1. Check for any P0 and P1 issues that should be dealt with before release. |
| 25 | +1. Check for any important issues that should be dealt with before release. |
79 | 26 |
|
80 | 27 | 2. Check for un-merged pull requests that should be merged before release.
|
81 | 28 |
|
|
0 commit comments