diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 2eeb75b0ec..865cda3dbc 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -159,14 +159,114 @@ In practice when we want to backport new API from main we have two options: 19d7e66099ee43f47d6be0e740dc710fc365d200. Then, on main we add duplicate symbols with commit 5eade4da11ee38a0e7faf4a87b2c2b5af07c5eeb. -### Reimporting systemd + +NetworkManager release process +------------------------------ + +It's mostly automated by [release.sh](contrib/fedora/rpm/release.sh). + +Before running the script: +- For stable releases, remember to backport all commits with "Fixes:" tag that + are applicable. Use the [find-backports](contrib/scripts/find-backports) + script to find them. +- Start all the jobs in the latest Gitlab pipeline of the right branch. The + script checks that they ran successfully. + Tiers 1 and 2 must pass, failed Tier 3 jobs can be fixed after the release. + +The script also takes care of choosing the right version number depending on the +release type that you specify, like devel, rc1, rc, major, major-post, etc. +Run the script with `--help` to see all options. + +Notes: +- You need access to master.gnome.org, see [here](https://handbook.gnome.org/infrastructure/accounts.html). +- The GPG key used to sign the tags must be exported to a keyserver. + +Versioning scheme, automatically handled by the script (version numbers are +called MAJOR.MINOR.MICRO): +- Development releases has an odd MINOR version number (i.e. `1.47.2`). +- Stable releases has an even MINOR version number (i.e. `1.48.1`). +- Release candidates (RC) are tagged like `1.48-rc1`, `1.48-rc2`, etc. But in + NM's internal code they looks like `1.47.90`, `1.47.91`, etc. (MINOR is one + number less, and MICRO is >= 90). + +The main differences between the different kind of releases are: +- Development releases: for depelopment and testing purposes only. +- Release candidates (RC): stabilization phase before a stable release. Normally + there are one or two RCs with ~2 weeks cadence. More RCs can be releases if + they are needed. +- Stable releases: Releases within the same stable branch should remain very + stable while fixing important bugs, backported from `main`. New features are + added very rarely. + +Stable branches are branched out from `main` to prepare the first release +candidate (RC) of the next stable branch. These branches are called `nm-MAJOR-MINOR` +(i.e. `nm-1-48`). As they are used to release stable versions, the last number +is always even. + +There are some additional tasks that the script doesn't handle: +- For RC releases: + - The NEWS file should reflect a curated summary of the changes that the new + stable release will include. + - The release should be announced on the mailing list. +- For stable releases: + - The official documentation must be updated on the website when there is a new + stable release. Use the [import-docs.sh](https://gitlab.freedesktop.org/NetworkManager/networkmanager.pages.freedesktop.org/-/blob/main/scripts/import-docs.sh) + script from the website's repo. + - The release should be announced on the mailing list. + + +VPN plugins and nm-applet release process +----------------------------------------- + +The same versioning scheme and release process is used for the VPN plugins, +nm-applet (including nm-connection-editor) and libnma. + +Note that each of them is hosted in its own repository, but this is documented +here to avoid duplication, as the process is the same for all (at least for +those that we maintain). + +Also note that there are no stable branches or development versions. Everything +is developed on main, and releases are done on main. + +Versioning scheme (version numbers are called MAJOR.MINOR.MICRO): +- Small changes increments only the MICRO number. +- Bigger changes or new features increments the MINOR number. +- There is no strict criteria to define what change is small or big, but try to + adhere mostly to [semantic versioning](https://semver.org/). +- Use only even numbers for MINOR, skipping odd ones. That way we use the same + versioning scheme than the main NM project despite there are no development + versions here. + +When doing a release, follow this process: +1. Ensure that `NEWS` file is up to date. +2. Increment the version in `configure.ac`, commit and tag the commit. Example: + `git tag -s 1.2.8 -m 'Tag 1.2.8'`. +3. Ensure that you are on the right commit and create the tarball: + `git clean -fdx && ./autogen.sh && make distcheck` +4. Upload the tarball: `scp ./*-*.tar.xz "$user@master.gnome.org:"` +5. Login to `master.gnome.org` and run `ftpadmin install`. + Ensure the new tarballs show up at https://download.gnome.org/sources/ + (happens after a short delay) +6. Announce the release on the mailing list. + +Notes: +- You need access to master.gnome.org, see [here](https://handbook.gnome.org/infrastructure/accounts.html). +- The GPG key used to sign the tags must be exported to a keyserver. + + +Reimporting systemd +------------------- See [here](src/libnm-systemd-shared/README.md#reimport-upstream-code). -### Copr repository + +Copr repository +--------------- See [here](contrib/scripts/nm-copr-build.sh). -### gitlab-ci Pipelines + +Gitlab-ci Pipelines +------------------- See [here](.gitlab-ci/README.md).