system/NetworkManager
system/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager synced 2024-10-02 22:38:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

doc: document how to do a release of NM and VPN plugins

Browse source 
Although VPN plugins are developed separately, better to document here
how to do the release of those that we maintain to avoid having to do
the changes on every repository each time.
This commit is contained in:
Íñigo Huguet 2024-05-06 14:08:22 +02:00
parent b8061dd4f6
commit 3ceeffb6b8
1 changed files with 103 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

106
MAINTAINERS.md
View file

@ -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).