| Age | Commit message (Collapse) | Author |
|
|
|
|
|
Co-authored-by: Théo Zimmermann <theo.zimmi@gmail.com>
|
|
|
|
Reviewed-by: Zimmi48
|
|
|
|
|
|
* Add hyperlinks
|
|
Also, stop pinging when copying checklist to new issue.
|
|
It is useful for the release process, and there is no reason for somebody
to lose time reimplementing it again.
|
|
Explain into the release process how to prepare the release notes.
|
|
Ack-by: ejgallego
Reviewed-by: vbgl
|
|
|
|
|
|
|
|
Related: coq/bignums#17
[ci skip]
|
|
In response to review comments by Zimmi48
|
|
We now support --master and --release. On the master branch, we support
four compatibility versions, while on releases and release branches, we
support only three compatibility versions.
We also support --git-add to automatically run `git add` with new and
updated files, and to run `git rm` with deleted files.
|
|
|
|
Also test that the compat updating script hasn't become outdated on the
CI.
|
|
As requested in
https://github.com/coq/coq/issues/8311#issuecomment-415976318
the release process describes the steps to take.
All automatable steps are taken by the new script
dev/tools/update-compat.py
I've tried to make the script relatively easy to update if functions get
renamed or moved, but since it's doing unstructured source manipulation,
it is sort-of fragile.
We could plausibly add a file to the test-suite to ensure that we catch
script-breakage early, but this would require dropping compatibility
support much earlier in the development cycle (the compatibility changes
would have to come right when the new version is branched, rather than
shortly before the beta release).
|
|
This process is expected to evolve in the future as we automate it more and more.
[ci skip]
|