-
Notifications
You must be signed in to change notification settings - Fork 658
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.12 #11157
Comments
@Zimmi48 I tweaked the start of the issue a bit to make it more compact; OMMV, changes are small tho; I will wait to tweak this more until we meet. |
Some topics for 8.12:
|
FTR, I am currently preparing the draft PR with the release notes. |
I will take care of the PR with the beta version bump. Two main points seem:
I understand @mattam82 is already working on the first item, how's the status on the second point tho? Seems like quite a complex process? |
I'll look into it possibly with help from @MSoegtropIMC. |
I am about to finish my reals PR and then will pick up the platform work. Do you have a timeline? |
Yes, and it is short (we're supposed to release 8.12+beta1 early next week). I'll work on this today. |
I see - unfortunately I have little time until the weekend, but I have time to review it and help in case you need it. You might want to take the file from the 8.11 release branch - it might be closer to what you finally need and contains in comments the reasoning for the picks I did then which is likely very similar for 8.12. |
Thanks, I'm using it as a reference, but virtually all tested projects have received compatibility fixes in 8.12, so they will all have to be updated. |
@erikmd Would you mind preparing a Docker image for Coq 8.12+beta1 (available on opam). |
Hi @Zimmi48, thanks for the ping! currently |
Regarding bignums, the compatible version is already in extra-dev, but for 8.12.0 I'll need to release coq-bignums.8.12.0 (say, from the last commit of the |
Yes, it sounds better to wait in case there's a last minute API change. |
Done:
|
Release announcements (for 8.12.1) will be done soon. This will be the last 8.12 release. |
Great work, thanks a lot @Zimmi48 |
Release process
As soon as 8.11 has branched off master and 8.12 RM have been nominated do:
X.X+beta1
milestone if it did not already exist.git tag -s
.The
VX.X+alpha
tag marks the first commit to be inmaster
and not in thebranch of the previous version.
release date) and put this information in the milestone (using the
description and due date fields), and in the release wiki page
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 / Discourse 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"
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-by
info 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.sh
to use commit hashes or tag (or, if itexists, a branch dedicated to compatibility with the corresponding
Coq branch).
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.
Before the beta release date
Coq has been tagged.
packages.
#7009).
is_a_released_version
totrue
inconfigure.ml
.VX.X+beta1
tag usinggit tag -s
.git push --tags --dry-run
that 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_version
tofalse
inconfigure.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-bignums
compatible version).coqorg/coq
(requires
coq-bignums
inextra-dev
for a beta / inreleased
for a final release).
upload them on GitHub.
(see coq/www#63).
and send announcement e-mails.
TODO: automate this.
At the final release time
#7271).
is_a_released_version
totrue
inconfigure.ml
.VX.X.0
tag.git push --tags --dry-run
that 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_version
tofalse
inconfigure.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.
At the patch-level release time
We generally do not update the magic numbers at this point (see
2881a18
).Compatibility Infrastructure Update
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: onceimmediately after branching with the
--master
flag (which setsup Coq to support four
-compat
flag arguments), in the samecommit as the one that updates
coq_version
inconfigure.ml
, and once again later on beforethe next branch point with the
--release
flag (see next section).The text was updated successfully, but these errors were encountered: