mirror of
https://github.com/clangd/clangd.git
synced 2024-12-04 21:17:10 +00:00
Page:
Release checklist
6
Release checklist
Nathan Ridge edited this page 2024-04-22 17:39:45 -04:00
Table of Contents
Checklist of tasks to do for every LLVM release.
Once the release branch is created
- Updates to the clangd website
- Go through any new config keys added in this release and document them
- File an issue at https://github.com/SchemaStore/schemastore/issues to track updating the JSON schema for the config file (example issue for clangd 17)
- Likewise for any notable new features
- Go through any new config keys added in this release and document them
- Contribute release notes to the LLVM website
- example: clangd 15 release notes
- (note: release notes for clangd 16 and 17 are missing, these were overlooked)
Once the LLVM release is out
- Prepare the clangd release on our Github releases page
- Steps for doing this:
- Go to https://github.com/clangd/clangd/actions/workflows/autobuild.yaml
- Click "Run workflow"
- In the "Branch" dropdown, leave the selection as
master
. (This is a branch in theclangd
repo, and does not interfere with the fact that we can build a commit from a release branch of thellvm-project
repo.) - In "Commit to build from", enter the full SHA of the appropriate tag from https://github.com/llvm/llvm-project/tags. For example, for releasing version 18.1.3, look at the tag
llvmorg-18.1.3
, and use the corresponding SHAc13b7485b87909fcf739f62cfa382b55407433c0
. - In "Repository to build from", leave the contents as
llvm/llvm-project
- In "Release name", put the full version, e.g.
18.1.3
- In "Tag name", put the same version, e.g.
18.1.3
- In "Release description", put e.g.
Stable clangd 18.1.3 release.
- Click "Run workflow"
- Wait for the builds to run. The release should be created automatically and the release packages attached to it once the build complete.
- Test out the binaries on as many platforms as possible, e.g. running
clangd --check=/tmp/foo.cc
to ensure binaries can "run".
- Steps for doing this:
- Mark the release as a stable release by unchecking the "pre-release" checkbox.
- Mark the release as latest after couple weeks if there are no issues. This will result in new binaries being picked up by vscode-clangd extension and some other integrations like chrome/llvm remote indexers and servers.