merge: branch 'ih/release_chgs'

Release: document how to release and stop doing "dev" releases on stable branches. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1932
2024-05-29 06:45:26 +00:00
parent b8061dd4f6 8eb00c0991
commit fdc6ac38f8
3 changed files with 114 additions and 25 deletions
--- 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).
--- a/5
+++ b/5
@@ -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
--- 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"
        ;;