This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

Branches

The current development branch is always master. Stable branches, are named nm-<major>-<minor> (nma-<major>-<minor> for applet). Commonly only the last stable branch receives updates, but if necessary also older versions will receive important fixes. Fixes to stable branches must always be backported from the next-newer stable branch, via git cherry-pick -x.

Versioning for NetworkManager

Since 1.0, stable versions always have an even minor and an even micro number (eg, 1.0.6, 1.2.0, or 1.2.14). Development versions of master have an odd minor number (eg, 1.5.0, 1.11.2, 1.11.5), while development versions of stable branches have an odd micro version (1.0.1, 1.10.1, 1.10.5).

development release on master

You can do that anytime. On master, the version number are like 1.9.0-dev, 1.9.1-dev, 1.9.2-dev, ..., 1.11.0-dev, 1.11.1-dev, etc.

All you need to do, is bump nm_micro_version in configure.ac, and tag git tag -s 1.11.3-dev -m 'Tag 1.11.3 (development)' (example).

minor stable release on a stable branch

On the stable branch (after the major release is already out), the version numbers are always like 1.8.1-dev, 1.8.3-dev, 1.8.5-dev, ..., 1.10.1-dev, 1.10.3-dev, etc.

To do a minor stable release, first make sure that the NEWS file is up to date. Then, bump nm_micro_version in configure.ac to an even number, ensure that NM_VERSION_CUR_STABLE and NM_VERSION_NEXT_STABLE in shared/nm-version-macros.h.in match to the new minor release, and tag the release with git tag -s 1.10.4 -m 'Tag 1.10.4 (bad example). Immediately following the release commit, bump the version number again to an odd nm_micro_version in configure.ac, update NM_VERSION_NEXT_STABLE in shared/nm-version-macros.h.in, and tag git tag -s 1.10.5-dev -m 'Tag 1.10.5 (development) (bad example).

first release candidate of new major release

This can only follow a development release on master while there is no release-candidate in progress, hence the current version number on master is like 1.9.1-dev, 1.9.2-dev, ..., 1.11.1-dev, etc.

First make sure that NEWS file is up to date. Then bump nm_micro_version in configure.ac to 90 and tag as git tag -s 1.10-rc1 -m 'Tag 1.10-rc1' (example).

On master, you immediately bump nm_minor_version again to an odd number and reset nm_micro_version to 0. Also, bump NM_VERSION_CUR_STABLE and NM_VERSION_NEXT_STABLE in shared/nm-version-macros.h.in. Also, , and make sure that NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED in libnm-core/nm-version.h and libnm-util/nm-version.h are extended. Tag as git tag -s 1.11.0-dev -m 'Tag 1.11.0 (development)' (example).

Create a new stable branch on the first release candidate (git branch nm-1-10 1.10-rc1) which from now on diverges from master.

further release candidates for major release

You are on a stable branch, and the version number is like 1.10-rc1 (1.9.90), 1.10-rc2 (1.9.91), etc.

Just bump nm_micro_version in configure.ac by one (90, 91, 92, etc.) and tag as git tag -s 1.10-rc3 -m 'Tag 1.10-rc3' (example).

new major release

You are on a stable branch, and after a first release candidate, like 1.10-rc1 (1.9.90), 1.10-rc2 (1.9.91), etc.

Ensure that the NEWS file is up to date. Increment nm_minor_version to the next even number and reset nm_micro_version in configure.ac. Ensure that both NM_VERSION_CUR_STABLE and NM_VERSION_NEXT_STABLE in shared/nm-version-macros.h.in match the new release. Then tag git commit -s 1.10.0 -m 'Tag 1.10.0' (example).

Immediately afterwards on the stable branch (nm-1-10), bump nm_micro_version in configure.ac to 1. Also, bump the micro version of NM_VERSION_NEXT_STABLE in shared/nm-version-macros.h.in and tag as git commit -s 1.10.1-dev -m 'Tag 1.10.1 (development)' (example).

Now, merge the new release 1.10.0 back into master (example) with making sure that

Versioning for applet and VPN plugins

The versioning for applet and VPN plugins follows the same scheme. In the following I talk about applet, but mean VPN plugins as well.

Note that the version number of NetworkManager, applet (and VPN plugins) does not need to be in sync and may diverge largely. In the past this was different, but that is no longer the case. There is one restriction though: the <major>.<minor> version of applet/plugins refers to the required libnm and server version. E.g. applet releases 1.8.0, 1.8.1-dev, 1.8.2, etc. all require a server and libnm version of 1.8.0 or newer.

So, unless master of the applet requires a newer libnm version, we only bump the micro version number. In the common cases, a release looks like

For stable branches like nm-1-2 or nma-1-2, micro releases work exactly the same as just explained on master.

In the very rare case when you need to bump the requirement to a new libnm version, you do instead:

library version

For libnm.so, libnm-util.so, and libnm-glib we use symbol versioning. We hence do not change -version-info, because it could not model the fact that a minor stable release might contains new backported ABI (link).

Checklist for releases of NetworkManager

Checklist for releases of nm-applet or VPN plugins

Note that releases of NetworkManager, applet, and VPN plugins are no longer done in sync. Each component can be released independently anytime. This also means, that the version numbers diverge. Note that the version major.minor number of applet and VPN plugins tells the required NetworkManager API. That is, nm-applet 1.8.x requires at least NetworkManager API 1.8.0 or newer.

2024-10-23 11:37