From 3ceeffb6b831c644669df6409f354dc26ed418f2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=8D=C3=B1igo=20Huguet?= Date: Mon, 6 May 2024 14:08:22 +0200 Subject: [PATCH 1/2] doc: document how to do a release of NM and VPN plugins 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. --- MAINTAINERS.md | 106 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 103 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 2eeb75b0e..865cda3db 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). From 8eb00c09910f8776f26e36af0369a4394b02d3e9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=8D=C3=B1igo=20Huguet?= Date: Mon, 6 May 2024 14:09:50 +0200 Subject: [PATCH 2/2] release.sh: stop doing "-dev" releases on stable branches Note: here I refer to the numbers in a version as MAJOR.MINOR.MICRO. Having stable and development releases do make sense for the MINOR version, because we maintain separate branches for them and they evolve separately. We have 1.47.z where we put all the changes so anyone can pick the latest development release and test it. At the same time, we have 1.46.z with the latest stable released version. However, it does not make sense to have 1.46.2 and 1.46.3-dev because the latter is not a development version. It is identical to 1.46.2, only the version number has been bumped, there are no changes to test. When we add commits, we will be actually testing 1.46.3-dev + some commits, which is exactly the same as testing 1.46.2 + some commits. So, basically, someone can use the releases of a development BRANCH, like 1.47.4, to test the development version of NM. But using a development MICRO version is exactly the same as using a non-development one. From now on, we will just increment the MICRO version each time we do a release on a stable branch and won't create the '-dev' tag. Update release.sh to do it this way. --- NEWS | 5 +++++ contrib/fedora/rpm/release.sh | 28 ++++++---------------------- 2 files changed, 11 insertions(+), 22 deletions(-) diff --git a/NEWS b/NEWS index 40c517326..ac07735a6 100644 --- a/NEWS +++ b/NEWS @@ -27,6 +27,11 @@ USE AT YOUR OWN RISK. NOT RECOMMENDED FOR PRODUCTION USE! when IPv6 device address was not explicitly passed on by ModemManager * Fix a performance issue that was leading to 100% CPU usage by NetworkManager if external programs were doing a big amount of routes updates. +* Patch-level development releases (i.e. 1.48.1-dev) won't be used anymore. + From now on, all the patch releases whithin a stable branch will be normal + releases, like 1.48.0, 1.48.1, 1.48.2, 1.48.3 and so on. + Odd numbers in the minor version number still indicates if it's a development + branch like 1.49 or a stable one like 1.48. ============================================= NetworkManager-1.46 diff --git a/contrib/fedora/rpm/release.sh b/contrib/fedora/rpm/release.sh index 809810f09..fd48f487d 100755 --- a/contrib/fedora/rpm/release.sh +++ b/contrib/fedora/rpm/release.sh @@ -14,12 +14,11 @@ # - "rc" : further release candidates on RC branch (e.g. from "nm-1-26" branch # tag "1.26-rc2" with version number 1.25.91). # - "major" : on stable branch do a major release (e.g. on "nm-1-26" branch -# release "1.26.0", followed by "1.26.1-dev"). +# release "1.26.0"). # You should do a "major-post" release right a "major" release. # - "major-post": after a "major" release, merge the release branch with main and # do another devel snapshot on main (e.g. do "1.27.1-dev" release). -# - "minor" : on a stable branch do a minor release (e.g. "1.26.4" on "nm-1-26" -# branch and bump to "1.26.5-dev"). +# - "minor" : on a stable branch do a minor release (e.g. "1.26.4" on "nm-1-26"). # # Requisites: # @@ -296,8 +295,7 @@ RC_VERSION= RELEASE_BRANCH= case "$RELEASE_MODE" in minor) - number_is_even "${VERSION_ARR[1]}" && - number_is_odd "${VERSION_ARR[2]}" || die "cannot do minor release on top of version $VERSION_STR" + number_is_even "${VERSION_ARR[1]}" || die "cannot do minor release on top of version $VERSION_STR" [ "$CUR_BRANCH" != main ] || die "cannot do a minor release on main" ;; devel) @@ -431,19 +429,13 @@ case "$RELEASE_MODE" in minor) set_version_number "${VERSION_ARR[0]}" "${VERSION_ARR[1]}" $(("${VERSION_ARR[2]}" + 1)) git commit -m "release: bump version to ${VERSION_ARR[0]}.${VERSION_ARR[1]}.$(("${VERSION_ARR[2]}" + 1))" -a || die "failed to commit release" - set_version_number "${VERSION_ARR[0]}" "${VERSION_ARR[1]}" $(("${VERSION_ARR[2]}" + 2)) - git commit -m "release: bump version to ${VERSION_ARR[0]}.${VERSION_ARR[1]}.$(("${VERSION_ARR[2]}" + 2)) (development)" -a || die "failed to commit devel version bump" b="${VERSION_ARR[0]}.${VERSION_ARR[1]}.$(("${VERSION_ARR[2]}" + 1))" - git tag -s -a -m "Tag $b" "$b" HEAD~ || die "failed to tag release" + git tag -s -a -m "Tag $b" "$b" HEAD || die "failed to tag release" BRANCHES+=("$b") CLEANUP_REFS+=("refs/tags/$b") BUILD_TAG="$b" - b="${VERSION_ARR[0]}.${VERSION_ARR[1]}.$(("${VERSION_ARR[2]}" + 2))" - git tag -s -a -m "Tag $b (development)" "$b-dev" HEAD || die "failed to tag devel version" - BRANCHES+=("$b-dev") - CLEANUP_REFS+=("refs/tags/$b-dev") - TAR_VERSION="$BUILD_TAG" + TAR_VERSION="$b" ;; devel) set_version_number "${VERSION_ARR[0]}" "${VERSION_ARR[1]}" $(("${VERSION_ARR[2]}" + 1)) @@ -482,20 +474,12 @@ case "$RELEASE_MODE" in ;; major) b="${VERSION_ARR[0]}.$((${VERSION_ARR[1]} + 1)).0" - b2="${VERSION_ARR[0]}.$((${VERSION_ARR[1]} + 1)).1" - set_version_number "${VERSION_ARR[0]}" "$((${VERSION_ARR[1]} + 1))" 0 git commit -m "release: bump version to $b" -a || die "failed to commit major version bump" + git tag -s -a -m "Tag $b" "$b" HEAD || die "failed to tag release" BRANCHES+=("$b") CLEANUP_REFS+=("refs/tags/$b") - - set_version_number "${VERSION_ARR[0]}" "$((${VERSION_ARR[1]} + 1))" 1 - git commit -m "release: bump version to $b2 (development)" -a || die "failed to commit another bump after major version bump" - git tag -s -a -m "Tag $b (development)" "$b2-dev" HEAD || die "failed to tag release" - BRANCHES+=("$b2-dev") - CLEANUP_REFS+=("refs/tags/$b2-dev") - BUILD_TAG="$b" TAR_VERSION="$b" ;;