Steps to a Successful Release

Add all items to NEWS
Update the contributors list in NEWS (ninja -C build git-contrib)
Update the time and place in NEWS
Update hwdb (ninja -C build update-hwdb, ninja -C build update-hwdb-autosuspend, commit separately).
Update syscall numbers (ninja -C build update-syscall-tables update-syscall-header).
[RC1] Update library numbers in meson.build
[RC1] Switch versionrewrite-pattern and versionrewrite-replacement to RC mode in https://build.opensuse.org/projects/system:systemd/packages/systemd/files/_service?expand=1
Update version number in meson.version (e.g. from 256~devel to 256~rc1 or from 256~rc3 to 256). Note that this uses a tilde (~) instead of a hyphen (-) because tildes sort lower in version comparisons according to the UAPI.10 Version Format Specification, and we want 255~rc1 to sort lower than 255.
Check dbus docs with ninja -C build update-dbus-docs
Check manpages list with ninja -C build update-man-rules
Update translation strings (ninja -C build systemd-pot, ninja -C build systemd-update-po) - drop the header comments from systemd.pot + re-add SPDX before committing. If the only change in a file is the 'POT-Creation-Date' field, then ignore that file.
Tag the release: version="v$(sed 's/~/-/g' meson.version)" && git tag -s "${version}" -m "systemd ${version}" (tildes are replaced with hyphens, because git doesn't accept the former).
Do ninja -C build
Make sure that the version string and package string match: build/systemctl --version
[FINAL] Close the github milestone and open a new one (https://github.com/systemd/systemd/milestones)
"Draft" a new release on github (https://github.com/systemd/systemd/releases/new), mark "This is a pre-release" if appropriate.
Check that announcement to systemd-devel, with a copy&paste from NEWS, was sent. This should happen automatically.
Update IRC topic (/msg chanserv TOPIC #systemd Version NNN released | Online resources https://systemd.io/)
[FINAL] Create an empty -stable branch: git push systemd origin/main:refs/heads/v${version}-stable.
[FINAL] Edit in the new -stable branch .obs/workflows.yml, changing project from system:systemd to system:systemd:stable and the branch from main to v${version}-stable. This should be backported to older active stable branches too.
[FINAL] Build and upload the documentation (on the -stable branch): ninja -C build doc-sync
[FINAL] Create a new ci/v${version}-stable branch for deb package builds on https://salsa.debian.org/systemd-team/systemd
[FINAL] Switch .semaphore/semaphore-runner.sh and mkosi/mkosi.pkgenv/mkosi.conf.d/debian-ubuntu.conf to the new ci/v${version}-stable branch on the -stable branch
[FINAL] Switch versionrewrite-pattern and versionrewrite-replacement to release mode in https://build.opensuse.org/projects/system:systemd/packages/systemd/files/_service?expand=1
[FINAL] Change the Github Pages branch to the newly created branch (https://github.com/systemd/systemd/settings/pages) and set the 'Custom domain' to 'systemd.io'
[FINAL] Update version number in meson.version to the devel version of the next release (e.g. from 256 to 257~devel)
[FINAL] Build and upload the documentation (on the main branch): ninja -C build doc-sync

Steps to a Successful Stable Release

Backport at least the commits from all PRs tagged with needs-stable-backport on Github with git cherry-pick -x. Any other commits that fix bugs, change documentation, tests, CI or mkosi can generally be backported as well. Since 256 the stable branches live here. Stable branches for older releases are available here. Check each commit to see if it makes sense to backport and check the comments on the PR to see if the author indicated that only specific commits should be backported.
Update the version number in meson.version (e.g. from 256.2 to 256.3) (only for 256-stable or newer)
Tag the release: version="v$(cat meson.version)" && git tag -s "${version}" -m "systemd-stable ${version}" (Fill in the version manually on releases older than 256)