davide/palladum-lightning
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

build: Update .version as part of the release

Browse Source
This commit is contained in:
Joseph Goulden
2024-09-30 21:54:00 +01:00
committed by Vincenzo Palazzo
parent fe7168b335
commit f31a8cf749
2 changed files with 11 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
Makefile
View File

@@ -726,7 +726,7 @@ clean: obsclean
PYLNS=client proto testing
# See doc/contribute-to-core-lightning/contributor-workflow.md
update-py-versions: update-pyln-versions update-clnrest-version update-wss-proxy-version update-poetry-lock
update-versions: update-pyln-versions update-clnrest-version update-wss-proxy-version update-poetry-lock update-dot-version
update-pyln-versions: $(PYLNS:%=update-pyln-version-%)
@@ -754,6 +754,10 @@ update-reckless-version:
@if [ -z "$(NEW_VERSION)" ]; then echo "Set NEW_VERSION!" >&2; exit 1; fi
@sed -i "s/__VERSION__ = '\([.-z]*\)'/__VERSION__ = '$(NEW_VERSION)'/" tools/reckless
update-dot-version:
@if [ -z "$(NEW_VERSION)" ]; then echo "Set NEW_VERSION!" >&2; exit 1; fi
echo $(NEW_VERSION) > .version
update-mocks: $(ALL_TEST_PROGRAMS:%=update-mocks/%.c)
$(ALL_TEST_PROGRAMS:%=update-mocks/%.c): $(ALL_GEN_HEADERS) $(EXTERNAL_LIBS) libccan.a ccan/ccan/cdump/tools/cdump-enumstr config.vars

12
doc/contribute-to-core-lightning/release-checklist.md
View File

@@ -15,16 +15,16 @@ Here's a checklist for the release process.
2. Look through outstanding issues, to identify any problems that might be necessary to fixup before the release. Good candidates are reports of the project not building on different architectures or crashes.
3. Identify a good lead for each outstanding issue, and ask them about a fix timeline.
4. Create a milestone for the _next_ release on Github, and go though open issues and PRs and mark accordingly.
5. Ask (via email) the most significant contributor who has not already named a release to name the release (use
5. Ask (via email) the most significant contributor who has not already named a release to name the release (use
`devtools/credit --verbose v<PREVIOUS-VERSION>` to find this contributor). CC previous namers and team.
## Preparing for -rc1
1. Check that `CHANGELOG.md` is well formatted, ordered in areas, covers all signficant changes, and sub-ordered approximately by user impact & coolness.
2. Use `devtools/changelog.py` to collect the changelog entries from pull request commit messages and merge them into the manually maintained `CHANGELOG.md`. This does API queries to GitHub, which are severely
2. Use `devtools/changelog.py` to collect the changelog entries from pull request commit messages and merge them into the manually maintained `CHANGELOG.md`. This does API queries to GitHub, which are severely
ratelimited unless you use an API token: set the `GH_TOKEN` environment variable to a Personal Access Token from <https://github.com/settings/tokens>
3. Create a new CHANGELOG.md heading to `v<VERSION>rc1`, and create a link at the bottom. Note that you should exactly copy the date and name format from a previous release, as the `build-release.sh` script relies on this.
4. Update the contrib/pyln package versions: `make update-py-versions NEW_VERSION=<VERSION>`
4. Update the package versions: `make update-versions NEW_VERSION=<VERSION>`
5. Create a PR with the above.
## Releasing -rc1
@@ -47,7 +47,7 @@ Here's a checklist for the release process.
## Releasing -rc2, ..., -rcN
1. Update CHANGELOG.md by changing rc(N-1) to rcN. Update the changelog list with information from newly merged PRs also.
2. Update the contrib/pyln package versions: `make update-py-versions NEW_VERSION=<VERSION>`
2. Update the package versions: `make update-versions NEW_VERSION=<VERSION>`
3. Add a PR with the rcN.
4. Tag it `git pull && git tag -s v<VERSION>rcN && git push --tags`
5. Draft a new `v<VERSION>rcN` pre-release on Github, upload reproducible builds, SHA256SUMS and SHA256SUMS.asc.
@@ -71,9 +71,9 @@ Here's a checklist for the release process.
- Build reproducible Ubuntu-v18.04, Ubuntu-v20.04, Ubuntu-v22.04 images. Follow [link](https://docs.corelightning.org/docs/repro#building-using-the-builder-image) for manually Building Ubuntu Images.
- Build Docker images for amd64 and arm64v8. Follow [link](https://docs.corelightning.org/docs/docker-images) for more details on Docker publishing.
- Create and sign checksums. Follow [link](https://docs.corelightning.org/docs/repro#co-signing-the-release-manifest) for manually signing the release.
6. The tarballs may be owned by root, so revert ownership if necessary:
6. The tarballs may be owned by root, so revert ownership if necessary:
`sudo chown ${USER}:${USER} *${VERSION}*`
7. Upload the resulting files to github and save as a draft.
7. Upload the resulting files to github and save as a draft.
(<https://github.com/ElementsProject/lightning/releases/>)
8. Send `SHA256SUMS` & `SHA256SUMS.asc` files to the rest of the team to check and sign the release.
9. Team members can verify the release with the help of `build-release.sh`: