Release 8.13 #12334
Assignees
Comments
|
Bench between V8.13+alpha and v8.13, more precisely Results are good, CC @ppedrot |
This was referenced Nov 24, 2020
|
@mattam82 next week is the last one before the beta, please give a shot to the credits |
Merged
|
@gares I think you should close this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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).
Done in Update to 8.13. #12346
Additionally, in the same commit, update the compatibility
infrastructure, which consists of invoking
dev/tools/update-compat.pywith the--masterflag.Note that the
update-compat.pyscript must be run twice: onceimmediately after branching with the
--masterflag (which setsup Coq to support four
-compatflag arguments), in the samecommit as the one that updates
coq_versioninconfigure.ml, and once again later on beforethe next branch point with the
--releaseflag (see next section).Put the corresponding alpha tag using
git tag -s.The
VX.X+alphatag marks the first commit to be inmasterand not in thebranch of the previous version.
Create the
X.X+beta1milestone 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
which consists of invoking
dev/tools/update-compat.pywith the--releaseflag; this sets up Coq to support three-compatflagarguments. To ensure that CI passes, you will have to decide what
to do about all test-suite files which mention
-compat U.UorCoq.Comapt.CoqUU(which is no longer valid, since we only keepcompatibility 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.0milestone 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.0milestone 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"
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.
The command that was used in the previous versions to get the list
of contributors for this version is
git shortlog -s -n VX.X+alpha..master | cut -f2 | sort -k 2. Note that the ordering isapproximative as it will misplace people with middle names. It is
also probably not correctly handling
Co-authored-byinfo that wehave been using more lately, so should probably be updated to
account for this.
On the date of the feature freeze
Create the new version branch
vX.X(using this name will ensure thatthe branch will be automatically protected).
Pin the versions of libraries and plugins in
dev/ci/ci-basic-overlays.shto use commit hashes or tag (or, if itexists, a branch dedicated to compatibility with the corresponding
Coq branch). You can use the
dev/tools/pin-ci.shscript to do thissemi-automatically.
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
masterthat 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 (inhtml_contextindoc/sphinx/conf.py).Before the beta release date
#10833): in a PR against the
masterbranch, move the contents from all files of
doc/changelog/that appear inthe release branch into the manual
doc/sphinx/changes.rst. Merge that PRinto the
masterbranch and backport it to the version branch.Coq has been tagged.
packages.
#7009).
is_a_released_versiontotrueinconfigure.ml.VX.X+beta1tag usinggit tag -s.git push --tags --dry-runthat you are notpushing anything else than the new tag. If needed, remove spurious
tags with
git tag -d. When this is OK, proceed withgit push --tags.is_a_released_versiontofalseinconfigure.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)
package managers can start preparing package updates (including a
coq-bignumscompatible version).coqin the opam repository (coq/opam-coq-archiveorocaml/opam-repository),the package managers can Cc
@erikmdto request that he prepare the necessary configuration for the Docker release incoqorg/coq(namely, he'll need to make sure a
coq-bignumsopam package is available inextra-dev, respectivelyreleased, so the Docker image gatheringcoqandcoq-bignumscan be built).should be sent as a link to the binary together with its SHA256 hash in a
signed e-mail, via our local contact (currently
@maximedenes).to
@maximedenes. A detailed step-by-step guide can be found on the wiki.(see coq/www#63).
TODO: setup some continuous deployment for this.
and send announcement e-mails.
At the final release time
#7271).
is_a_released_versiontotrueinconfigure.ml.VX.X.0tag.git push --tags --dry-runthat you are notpushing anything else than the new tag. If needed, remove spurious
tags with
git tag -d. When this is OK, proceed withgit push --tags.is_a_released_versiontofalseinconfigure.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
@Zimmi48to:At the patch-level release time
We generally do not update the magic numbers at this point (see
2881a18).The text was updated successfully, but these errors were encountered: