-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 8.19 #18087
Comments
ping @erikmd for 8.19+rc1 |
ping @erikmd for 8.19.0 |
ping @erikmd for 8.19.1 |
FYI @SkySkimmer
|
ping @erikmd for 8.19.2 |
Ping @Zimmi48 to publish a new version on Zenodo. |
Finally done for 8.18 and 8.19! |
Release checklist
When the release managers for version
X.X
get nominateddev/doc/release-process.md
.About one month before the branching date
X.X.0
) and the following major release (Y.Y+rc1
) milestones if they do not already exist.X.X+rc1
milestone any feature and clean up PRs that they already know won't be ready on time.master
, calldev/tools/update-compat.py
with the--release
flag; this sets up Coq to support three-compat
flag arguments including the upcoming one (instead of four). To ensure that CI passes, you will have to decide what to do about all test-suite files that mention-compat U.U
orCoq.Compat.CoqUU
(which is no longer valid, since we only keep compatibility against the two previous versions), and you may have to ping maintainers of projects that are still relying on the old compatibility flag so that they fix this. (update-compat --release for 8.19 #18237)master
(not yet to be merged) changing the version name to the next major version and both magic numbers intools/configure/configure.ml
. For example, for8.5
, the version name will be8.5+alpha
while the magic numbers will end with80490
.Additionally, in the same commit, update the compatibility infrastructure, which consists of invoking
dev/tools/update-compat.py
with the--master
flag.Note that the
update-compat.py
script must be run twice: once in preparation of the release with the--release
flag (see earlier in this section) and once on the branching date with the--master
flag to mark the start of the next version.This PR should be opened before the branching date to have time to deal with CI issues, but should not be merged until branching.
On the branching date
vX.X
branch from the last merge commit before this one (using this name will ensure that the branch will be automatically protected).git tag -s
. TheVY.Y+alpha
tag marks the first commit to be inmaster
and not in thevX.X
release branch. Note that this commit is the first commit in the first PR merged in master, not the merge commit for that PR. Therefore, if you proceeded as described above, this should be the commit updating the version, magic numbers and compatibility infrastructure. After tagging, double-check thatgit describe
picks up the tag you just made (if not, you tagged the wrong commit).git push upstream VY.Y+alpha --dry-run
(remove the--dry-run
and redo if everything looks OK).Request X.X+rc1 inclusion
column for the PRs that were merged inmaster
that are to be considered for backporting, and aShipped in X.X+rc1
columns to put what was backported. A message to@coqbot
in the milestone description tells it to automatically add merged PRs to theRequest ... inclusion
column and backported PRs to theShipped in ...
column. See previous milestones for examples. When moving to the next milestone (e.g.X.X.0
), you can clear and remove theRequest X.X+rc1 inclusion
column and create newRequest X.X.0 inclusion
andShipped in X.X.0
columns.The release manager is the person responsible for merging PRs that target the release branch and backporting appropriate PRs (mostly safe bug fixes, user message improvements and documentation updates) that are merged into
master
.dev/ci/ci-basic-overlay.sh
to use commit hashes. You can use thedev/tools/pin-ci.sh
script to do this semi-automatically.master
to be backported, add a new link to the'versions'
list of the refman (inhtml_context
indoc/sphinx/conf.py
).@Zimmi48
and@erikmd
to set up the infrastructure to have alpha Docker images built for the branch.In the days following the branching
master
to be backported, generate the release changelog by callingdev/tools/generate-release-changelog.sh
and include it in a new section indoc/sphinx/changes.rst
.The script automatically reorders the entries to show first the Changed, then the Removed, Deprecated, Added and last the Fixed. Manual adjustement is still needed when multiple entries are combined in a single changelog file.
@mattam82
) to get him started on writing the release summary.The
dev/tools/list-contributors.sh
script computes the number and list of contributors between Coq revisions. Typically used withVX.X+alpha..vX.X
to check the contributors of versionVX.X
.Note that this script relies on
.mailmap
to merge multiple identities. If you notice anything incorrect while using it, use the opportunity to fix the.mailmap
file. Same thing if you want to have the full name of a contributor shown instead of a pseudonym.CACHEKEY
variables in.gitlab-ci.yml
(for instanceold_ubuntu_lts-V2022-05-20-c34331afa5
to"old_ubuntu_lts-v8.16-V2022-05-20-c34331afa5
) to indicate that it shouldn't be cleaned up even once it gets old. This should be done after all PRs touching theCACHEKEY
variables have been merged.For each release (preview, final, patch-level)
vX.X
(for testing):tools/configure/configure.ml
.is_a_released_version
totrue
.VX.X...
usinggit tag -s
.git push upstream VX.X... --dry-run
(remove the--dry-run
and redo if everything looks OK).is_a_released_version
tofalse
(if you forget about it, you'll be reminded by the test-suite failing whenever you try to backport a PR with a changelog entry).coq-bignums
compatible version).core-dev
category of the coq/opam-coq-archive for preview releases.@erikmd
to request that he prepares the necessary configuration for the Docker release incoqorg/coq
(namely, he'll need to make sure acoq-bignums
opam package is available inextra-dev
, respectivelyreleased
, so the Docker image gatheringcoq
andcoq-bignums
can be built).doc:refman-pdf
job from continuous integration.For the first release candidate release
For each non-preview release
incl/macros.html
on the website.@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 twoProxyPass
lines (one for the refman and one for the stdlib doc) withsudo vim /etc/apache2/sites-available/000-coq.inria.fr.conf
, then runningsudo systemctl reload apache2
.TODO: automate this or make it doable through the
www
git repository. See coq/www#111 and coq/www#131.Only for the final release of each major version
@Zimmi48
to publish a new version on Zenodo.TODO: automate this with coqbot.
This is now delegated to the platform maintainers
dsi.securite
@inria.fr
putting@maximedenes
in carbon copy.Then ask a Platform maintainer with access to the store to publish the upload or give you access so that you can do it yourself.
The text was updated successfully, but these errors were encountered: