shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-01-11 09:18:07 +03:00
Code
efedb6b0f3
systemd/docs/RELEASE.md

36 lines
3.3 KiB
Markdown
Raw Normal View History

docs: add a "front matter" snippet to our markdown pages It turns out Jekyll (the engine behind GitHub Pages) requires that pages include a "Front Matter" snippet of YAML at the top for proper rendering. Omitting it will still render the pages, but including it opens up new possibilities, such as using a {% for %} loop to generate index.md instead of requiring a separate script. I'm hoping this will also fix the issue with some of the pages (notably CODE_OF_CONDUCT.html) not being available under systemd.io Tested locally by rendering the website with Jekyll. Before this change, the *.md files were kept unchanged (so not sure how that even works?!), after this commit, proper *.html files were generated from it.
2019-01-03 01:16:34 +03:00
---
title: Steps to a Successful Release
docs: place all our markdown docs in rough categories
2019-12-11 12:49:28 +03:00
category: Contributing
docs: make it pretty Add custom Jekyll theme, logo, webfont and .gitignore FIXME: the markdown files have some H1 headers which need to be replaced with H2
2019-12-11 19:01:46 +03:00
layout: default
docs: add spdx tags to all .md files I have no idea if this is going to cause rendering problems, and it is fairly hard to check. So let's just merge this, and if it github markdown processor doesn't like it, revert.
2021-09-14 17:05:21 +03:00
SPDX-License-Identifier: LGPL-2.1-or-later
docs: add a "front matter" snippet to our markdown pages It turns out Jekyll (the engine behind GitHub Pages) requires that pages include a "Front Matter" snippet of YAML at the top for proper rendering. Omitting it will still render the pages, but including it opens up new possibilities, such as using a {% for %} loop to generate index.md instead of requiring a separate script. I'm hoping this will also fix the issue with some of the pages (notably CODE_OF_CONDUCT.html) not being available under systemd.io Tested locally by rendering the website with Jekyll. Before this change, the *.md files were kept unchanged (so not sure how that even works?!), after this commit, proper *.html files were generated from it.
2019-01-03 01:16:34 +03:00
---
docs: uppercase the title of our Markdown docs
2018-11-29 13:09:09 +03:00
# Steps to a Successful Release
Add RELEASE.md file which lists the steps needed for release I put it in .github, so it doesn't stand out too much; after all it's not interesting to most people.
2016-05-31 20:43:41 +03:00
1. Add all items to NEWS
docs: stop recommending meson compile With meson-0.60, meson compile stopped working with some targets: $ meson compile -C build update-man-rules ERROR: Can't invoke target `update-man-rules`: ambiguous name. Add target type and/or path: `PATH/NAME:TYPE` This is obviously a regression in meson, but based on a chat with the maintainers, it seems that there's some disagreement as to whether 'meson compile' is useful and how exactly it should work. Since we're already at meson 0.60.3 and this hasn't been fixed, and people generally don't seem to consider this an issue, let's return to documenting the usual practice of 'ninja -C build' that just works everywhere. (Since nobody has raised any fuss in systemd, it means that people are generally using the shorter form during development too. I only noticed because I pasted a command from the release docs when preparing -rc1.)
2022-04-12 13:05:53 +03:00
2. Update the contributors list in NEWS (`ninja -C build git-contrib`)
Add RELEASE.md file which lists the steps needed for release I put it in .github, so it doesn't stand out too much; after all it's not interesting to most people.
2016-05-31 20:43:41 +03:00
3. Update the time and place in NEWS
docs/RELEASE: also mention syscall tables
2022-04-12 13:33:33 +03:00
4. Update hwdb (`ninja -C build update-hwdb`, `ninja -C build update-hwdb-autosuspend`, commit separately).
docs/RELEASE: typo in target name
2022-05-05 20:49:26 +03:00
5. Update syscall numbers (`ninja -C build update-syscall-tables update-syscall-header`).
meson: Start adding devel and rc suffixes to the project version Let's make sure that versions generated by meson-vcs-tag.sh always sort higher than official and stable releases. We achieve this by immediately updating the meson version in meson.build after a new release. To make sure this version always sorts lower than future rcs, we suffix it with "~devel" which will sort lower than "~rcX". The new release workflow is to update the version in meson.build for each rc and the official release and to also update the version number after a new release to the next development version. The full version is exposed as PROJECT_VERSION_FULL and used where it makes sense over PROJECT_VERSION. We also switch to reading the version from a meson.version file in the repo instead of hardcoding it in meson.build. This makes it easier to access both inside and outside of the project. The meson-vcs-tag.sh script is rewritten to query the version from meson.version instead of passing it in via the command line. This makes it easier to use outside of systemd since users don't have to query the version themselves first.
2024-02-14 13:04:36 +03:00
6. [RC1] Update library numbers in `meson.build`
docs/RELEASE: meson.version doesn't contain "v" prefix
2024-05-13 15:08:25 +03:00
7. 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 [version format specification](https://uapi-group.org/specifications/specs/version_format_specification/), and we want `255~rc1` to sort lower than `255`.
meson: Start adding devel and rc suffixes to the project version Let's make sure that versions generated by meson-vcs-tag.sh always sort higher than official and stable releases. We achieve this by immediately updating the meson version in meson.build after a new release. To make sure this version always sorts lower than future rcs, we suffix it with "~devel" which will sort lower than "~rcX". The new release workflow is to update the version in meson.build for each rc and the official release and to also update the version number after a new release to the next development version. The full version is exposed as PROJECT_VERSION_FULL and used where it makes sense over PROJECT_VERSION. We also switch to reading the version from a meson.version file in the repo instead of hardcoding it in meson.build. This makes it easier to access both inside and outside of the project. The meson-vcs-tag.sh script is rewritten to query the version from meson.version instead of passing it in via the command line. This makes it easier to use outside of systemd since users don't have to query the version themselves first.
2024-02-14 13:04:36 +03:00
8. Check dbus docs with `ninja -C build update-dbus-docs`
docs: update translation-related instructions Just making them consistent with the rest of the doc.
2024-03-04 12:11:34 +03:00
9. 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.
docs/RELEASE: use meson.version for tags
2024-05-13 15:05:40 +03:00
10. 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).
meson: Start adding devel and rc suffixes to the project version Let's make sure that versions generated by meson-vcs-tag.sh always sort higher than official and stable releases. We achieve this by immediately updating the meson version in meson.build after a new release. To make sure this version always sorts lower than future rcs, we suffix it with "~devel" which will sort lower than "~rcX". The new release workflow is to update the version in meson.build for each rc and the official release and to also update the version number after a new release to the next development version. The full version is exposed as PROJECT_VERSION_FULL and used where it makes sense over PROJECT_VERSION. We also switch to reading the version from a meson.version file in the repo instead of hardcoding it in meson.build. This makes it easier to access both inside and outside of the project. The meson-vcs-tag.sh script is rewritten to query the version from meson.version instead of passing it in via the command line. This makes it easier to use outside of systemd since users don't have to query the version themselves first.
2024-02-14 13:04:36 +03:00
11. Do `ninja -C build`
12. Make sure that the version string and package string match: `build/systemctl --version`
13. [FINAL] Close the github milestone and open a new one (https://github.com/systemd/systemd/milestones)
14. "Draft" a new release on github (https://github.com/systemd/systemd/releases/new), mark "This is a pre-release" if appropriate.
15. Check that announcement to systemd-devel, with a copy&paste from NEWS, was sent. This should happen automatically.
16. Update IRC topic (`/msg chanserv TOPIC #systemd Version NNN released | Online resources https://systemd.io/`)
docs: update RELEASE.md to use same repository for stable branches
2024-06-12 01:07:17 +03:00
17. [FINAL] Create an empty -stable branch: `git push systemd origin/main:refs/heads/v${version}-stable`.
meson: Start adding devel and rc suffixes to the project version Let's make sure that versions generated by meson-vcs-tag.sh always sort higher than official and stable releases. We achieve this by immediately updating the meson version in meson.build after a new release. To make sure this version always sorts lower than future rcs, we suffix it with "~devel" which will sort lower than "~rcX". The new release workflow is to update the version in meson.build for each rc and the official release and to also update the version number after a new release to the next development version. The full version is exposed as PROJECT_VERSION_FULL and used where it makes sense over PROJECT_VERSION. We also switch to reading the version from a meson.version file in the repo instead of hardcoding it in meson.build. This makes it easier to access both inside and outside of the project. The meson-vcs-tag.sh script is rewritten to query the version from meson.version instead of passing it in via the command line. This makes it easier to use outside of systemd since users don't have to query the version themselves first.
2024-02-14 13:04:36 +03:00
18. [FINAL] Build and upload the documentation (on the -stable branch): `ninja -C build doc-sync`
docs: update RELEASE.md to use same repository for stable branches
2024-06-12 01:07:17 +03:00
20. [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'
meson: Start adding devel and rc suffixes to the project version Let's make sure that versions generated by meson-vcs-tag.sh always sort higher than official and stable releases. We achieve this by immediately updating the meson version in meson.build after a new release. To make sure this version always sorts lower than future rcs, we suffix it with "~devel" which will sort lower than "~rcX". The new release workflow is to update the version in meson.build for each rc and the official release and to also update the version number after a new release to the next development version. The full version is exposed as PROJECT_VERSION_FULL and used where it makes sense over PROJECT_VERSION. We also switch to reading the version from a meson.version file in the repo instead of hardcoding it in meson.build. This makes it easier to access both inside and outside of the project. The meson-vcs-tag.sh script is rewritten to query the version from meson.version instead of passing it in via the command line. This makes it easier to use outside of systemd since users don't have to query the version themselves first.
2024-02-14 13:04:36 +03:00
21. [FINAL] Update version number in `meson.version` to the devel version of the next release (e.g. from `v256` to `v257~devel`)
docs: Document how to do stable releases
2024-07-19 15:00:04 +03:00
# Steps to a Successful Stable Release
1. 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](https://github.com/systemd/systemd/). Stable branches for older releases are available [here](https://github.com/systemd/systemd-stable/). 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.
2. Update the version number in `meson.version` (e.g. from `256.2` to `256.3`) (only for 256-stable or newer)
3. 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)
Copy Permalink