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
This commit is contained in:
106
MAINTAINERS.md
106
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
|
19d7e66099ee43f47d6be0e740dc710fc365d200. Then, on main we add duplicate
|
||||||
symbols with commit 5eade4da11ee38a0e7faf4a87b2c2b5af07c5eeb.
|
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).
|
See [here](src/libnm-systemd-shared/README.md#reimport-upstream-code).
|
||||||
|
|
||||||
### Copr repository
|
|
||||||
|
Copr repository
|
||||||
|
---------------
|
||||||
|
|
||||||
See [here](contrib/scripts/nm-copr-build.sh).
|
See [here](contrib/scripts/nm-copr-build.sh).
|
||||||
|
|
||||||
### gitlab-ci Pipelines
|
|
||||||
|
Gitlab-ci Pipelines
|
||||||
|
-------------------
|
||||||
|
|
||||||
See [here](.gitlab-ci/README.md).
|
See [here](.gitlab-ci/README.md).
|
||||||
|
5
NEWS
5
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
|
when IPv6 device address was not explicitly passed on by ModemManager
|
||||||
* Fix a performance issue that was leading to 100% CPU usage by NetworkManager
|
* Fix a performance issue that was leading to 100% CPU usage by NetworkManager
|
||||||
if external programs were doing a big amount of routes updates.
|
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
|
NetworkManager-1.46
|
||||||
|
@@ -14,12 +14,11 @@
|
|||||||
# - "rc" : further release candidates on RC branch (e.g. from "nm-1-26" branch
|
# - "rc" : further release candidates on RC branch (e.g. from "nm-1-26" branch
|
||||||
# tag "1.26-rc2" with version number 1.25.91).
|
# 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
|
# - "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.
|
# You should do a "major-post" release right a "major" release.
|
||||||
# - "major-post": after a "major" release, merge the release branch with main and
|
# - "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).
|
# 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"
|
# - "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").
|
|
||||||
#
|
#
|
||||||
# Requisites:
|
# Requisites:
|
||||||
#
|
#
|
||||||
@@ -296,8 +295,7 @@ RC_VERSION=
|
|||||||
RELEASE_BRANCH=
|
RELEASE_BRANCH=
|
||||||
case "$RELEASE_MODE" in
|
case "$RELEASE_MODE" in
|
||||||
minor)
|
minor)
|
||||||
number_is_even "${VERSION_ARR[1]}" &&
|
number_is_even "${VERSION_ARR[1]}" || die "cannot do minor release on top of version $VERSION_STR"
|
||||||
number_is_odd "${VERSION_ARR[2]}" || die "cannot do minor release on top of version $VERSION_STR"
|
|
||||||
[ "$CUR_BRANCH" != main ] || die "cannot do a minor release on main"
|
[ "$CUR_BRANCH" != main ] || die "cannot do a minor release on main"
|
||||||
;;
|
;;
|
||||||
devel)
|
devel)
|
||||||
@@ -431,19 +429,13 @@ case "$RELEASE_MODE" in
|
|||||||
minor)
|
minor)
|
||||||
set_version_number "${VERSION_ARR[0]}" "${VERSION_ARR[1]}" $(("${VERSION_ARR[2]}" + 1))
|
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"
|
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))"
|
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")
|
BRANCHES+=("$b")
|
||||||
CLEANUP_REFS+=("refs/tags/$b")
|
CLEANUP_REFS+=("refs/tags/$b")
|
||||||
BUILD_TAG="$b"
|
BUILD_TAG="$b"
|
||||||
b="${VERSION_ARR[0]}.${VERSION_ARR[1]}.$(("${VERSION_ARR[2]}" + 2))"
|
TAR_VERSION="$b"
|
||||||
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"
|
|
||||||
;;
|
;;
|
||||||
devel)
|
devel)
|
||||||
set_version_number "${VERSION_ARR[0]}" "${VERSION_ARR[1]}" $(("${VERSION_ARR[2]}" + 1))
|
set_version_number "${VERSION_ARR[0]}" "${VERSION_ARR[1]}" $(("${VERSION_ARR[2]}" + 1))
|
||||||
@@ -482,20 +474,12 @@ case "$RELEASE_MODE" in
|
|||||||
;;
|
;;
|
||||||
major)
|
major)
|
||||||
b="${VERSION_ARR[0]}.$((${VERSION_ARR[1]} + 1)).0"
|
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
|
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 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"
|
git tag -s -a -m "Tag $b" "$b" HEAD || die "failed to tag release"
|
||||||
BRANCHES+=("$b")
|
BRANCHES+=("$b")
|
||||||
CLEANUP_REFS+=("refs/tags/$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"
|
BUILD_TAG="$b"
|
||||||
TAR_VERSION="$b"
|
TAR_VERSION="$b"
|
||||||
;;
|
;;
|
||||||
|
Reference in New Issue
Block a user