1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
# Release process #
## As soon as the previous version branched off master ##
In principle, these steps should be undertaken by the RM of the next
release. Unfortunately, we have not yet been able to nominate RMs
early enough in the process for this person to be known at that point
in time.
- [ ] Create a new issue to track the release process where you can copy-paste
the present checklist from `dev/doc/release-process.md`.
- [ ] Change the version name to the next major version and the magic
numbers (see [#7008](https://github.com/coq/coq/pull/7008/files)).
Additionally, in the same commit, update the compatibility
infrastructure, which consists of invoking
[`dev/tools/update-compat.py`](../tools/update-compat.py) with the
`--master` flag.
Note that the `update-compat.py` script must be run twice: once
*immediately after* branching with the `--master` flag (which sets
up Coq to support four `-compat` flag arguments), *in the same
commit* as the one that updates `coq_version` in
[`configure.ml`](../../configure.ml), and once again later on before
the next branch point with the `--release` flag (see next section).
- [ ] Put the corresponding alpha tag using `git tag -s`.
The `VX.X+alpha` tag marks the first commit to be in `master` and not in the
branch of the previous version. Note that this commit is the first commit
in the first PR merged in master, not the merge commit for that PR.
After tagging double check that `git describe` picks up
the tag you just made (if not, you tagged the wrong commit).
- [ ] Create the `X.X+beta1` milestone if it did not already exist.
- [ ] Decide the release calendar with the team (freeze date, beta date, final
release date) and put this information in the milestone (using the
description and due date fields).
## Anytime after the previous version is branched off master ##
- [ ] Update the compatibility infrastructure to the next release,
which consists of invoking
[`dev/tools/update-compat.py`](../tools/update-compat.py) with the
`--release` flag; this sets up Coq to support three `-compat` flag
arguments. To ensure that CI passes, you will have to decide what
to do about all test-suite files which mention `-compat U.U` or
`Coq.Comapt.CoqUU` (which is no longer valid, since we only keep
compatibility against the two previous versions on releases), and
you may have to prepare overlays for projects using the
compatibility flags.
## About one month before the beta ##
- [ ] Create the `X.X.0` milestone and set its due date.
- [ ] Send an announcement of the upcoming freeze on Coqdev and ask people to
remove from the beta milestone what they already know won't be ready on time
(possibly postponing to the `X.X.0` milestone for minor bug fixes,
infrastructure and documentation updates).
- [ ] Determine which issues should / must be fixed before the beta, add them
to the beta milestone, possibly with a
["priority: blocker"](https://github.com/coq/coq/labels/priority%3A%20blocker)
label. Make sure that all these issues are assigned (and that the assignee
provides an ETA).
- [ ] Ping the development coordinator (**@mattam82**) to get him started on
the update to the Credits chapter of the reference manual.
See also [#7058](https://github.com/coq/coq/issues/7058).
The `dev/tools/list-contributors.sh` script computes the number and
list of contributors between Coq revisions. Typically used with
`VX.X+alpha..vX.X` to check the contributors of version `VX.X`.
## On the date of the feature freeze ##
- [ ] Create the new version branch `vX.X` (using this name will ensure that
the branch will be automatically protected).
- [ ] Pin the versions of libraries and plugins in
`dev/ci/ci-basic-overlays.sh` to use commit hashes or tag (or, if it
exists, a branch dedicated to compatibility with the corresponding
Coq branch). You can use the `dev/tools/pin-ci.sh` script to do this
semi-automatically.
- [ ] Notify upstream authors about the pinning, see
`dev/tools/notify-upstream-pins.sh`. As of today there is no automated
way to track these issues.
- [ ] Remove all remaining unmerged feature PRs from the beta milestone.
- [ ] Start a new project to track PR backporting. The project should
have a "Request X.X+beta1 inclusion" column for the PRs that were
merged in `master` that are to be considered for backporting, and a
"Shipped in X.X+beta1" columns to put what was backported. A message
to **@coqbot** in the milestone description tells it to
automatically add merged PRs to the "Request ... inclusion" column
and backported PRs to the "Shipped in ..." column. See previous
milestones for examples. When moving to the next milestone
(e.g. X.X.0), you can clear and remove the "Request X.X+beta1
inclusion" column and create new "Request X.X.0 inclusion" and
"Shipped in X.X.0" columns.
The release manager is the person responsible for merging PRs that
target the version branch and backporting appropriate PRs that are
merged into `master`.
- [ ] Delay non-blocking issues to the appropriate milestone and ensure
blocking issues are solved. If required to solve some blocking issues,
it is possible to revert some feature PRs in the version branch only.
- [ ] Add a new link to the ``'versions'`` list of the refman (in
``html_context`` in ``doc/sphinx/conf.py``).
## Before the beta release date ##
- [ ] Ensure the Credits chapter has been updated.
- [ ] Prepare the release notes (see e.g.,
[#10833](https://github.com/coq/coq/pull/10833)): in a PR against the `master`
branch, move the contents from all files of `doc/changelog/` that appear in
the release branch into the manual `doc/sphinx/changes.rst`. Merge that PR
into the `master` branch and backport it to the version branch.
- [ ] Ensure that an appropriate version of the plugins we will distribute with
Coq has been tagged.
- [ ] Have some people test the recently auto-generated Windows and MacOS
packages.
- [ ] In a PR against `vX.X` (for testing):
- Change the version name from alpha to beta1 (see
[#7009](https://github.com/coq/coq/pull/7009/files)).
- We generally do not update the magic numbers at this point.
- Set `is_a_released_version` to `true` in `configure.ml`.
- [ ] Put the `VX.X+beta1` tag using `git tag -s`.
- [ ] Push the new tag with `git push upstream VX.X+beta1 --dry-run`
(remove the `--dry-run` and redo if all looks OK).
- [ ] Set `is_a_released_version` to `false` in `configure.ml`
(if you forget about it, you'll be reminded whenever you try to
backport a PR with a changelog entry).
### These steps are the same for all releases (beta, final, patch-level) ###
- [ ] Send an e-mail on Coqdev announcing that the tag has been put so that
package managers can start preparing package updates (including a
`coq-bignums` compatible version).
- [ ] When opening the corresponding PR for `coq` in the opam repository ([`coq/opam-coq-archive`](https://github.com/coq/opam-coq-archive) or [`ocaml/opam-repository`](https://github.com/ocaml/opam-repository)),
the package managers can Cc `@erikmd` to request that he prepare the necessary configuration for the Docker release in [`coqorg/coq`](https://hub.docker.com/r/coqorg/coq)
(namely, he'll need to make sure a `coq-bignums` opam package is available in [`extra-dev`](https://github.com/coq/opam-coq-archive/tree/master/extra-dev), respectively [`released`](https://github.com/coq/opam-coq-archive/tree/master/released), so the Docker image gathering `coq` and `coq-bignums` can be built).
- [ ] Draft a release on GitHub.
- [ ] Sign the Windows and MacOS packages and upload them on GitHub.
+ The Windows packages must be signed by the Inria IT security service. They
should be sent as a link to the binary (via [filesender](https://filesender.renater.fr) for example)
together with its SHA256 hash in a signed e-mail to `dsi.securite` @ `inria.fr`
putting `@maximedenes` in carbon copy.
+ The MacOS packages should be signed with our own certificate. A detailed step-by-step guide can be found [on the wiki](https://github.com/coq/coq/wiki/SigningReleases).
- [ ] Upload the PDF version of the reference manual to the GitHub release. (*TODO:* automate this.)
- [ ] Prepare a page of news on the website with the link to the GitHub release
(see [coq/www#63](https://github.com/coq/www/pull/63)).
- [ ] Merge the website update, publish the release
and send announcement e-mails, typically on
the `coq-club@inria.fr` mailing list and the discourse forum
([posting by mail](https://github.com/coq/coq/wiki/Discourse))
- [ ] Close the milestone
## At the final release time ##
- [ ] Prepare the release notes (see above)
- [ ] In a PR against `vX.X` (for testing):
- Change the version name from X.X.0 and the magic numbers (see
[#7271](https://github.com/coq/coq/pull/7271/files)).
- Set `is_a_released_version` to `true` in `configure.ml`.
- [ ] Put the `VX.X.0` tag.
- [ ] Push the new tag with `git push upstream VX.X.0 --dry-run`
(remove the `--dry-run` and redo if all looks OK).
- [ ] Set `is_a_released_version` to `false` in `configure.ml`
(if you forget about it, you'll be reminded whenever you try to
backport a PR with a changelog entry).
Repeat the generic process documented above for all releases.
Ping `@Zimmi48` to:
- [ ] Switch the default version of the reference manual on the website.
This is done by logging into the server (`vps697916.ovh.net`),
editing two `ProxyPass` lines (one for the refman and one for the
stdlib doc) with `sudo vim /etc/apache2/sites-available/000-coq.inria.fr.conf`,
then running `sudo systemctl reload apache2`.
*TODO:* automate this or make it doable through the `www` git
repository. See [coq/www#111](https://github.com/coq/www/issues/111)
and [coq/www#131](https://github.com/coq/www/issues/131).
- [ ] Publish a new version on Zenodo (only once per major version).
*TODO:* automate this with coqbot.
## At the patch-level release time ##
We generally do not update the magic numbers at this point (see
[`2881a18`](https://github.com/coq/coq/commit/2881a18)).
|
