NM always has at least two maintained branches:

  • development - 'git master'; always expected to be buildable and runnable day-to-day, as features are developed on branches and only merged when they are ready. Often the next minor version of the current stable series, and always an odd-numbered release (eg, development is 1.1.0 while stable is 1.0.0).

  • stable - the last major version release; receives bug fixes and sometimes backports of self-contained-features. End users are encouraged to run releases from this branch.

Sometimes, there's another one:

  • maintenance - the last major version release, receives maintenance and minor updates only. After a few 'stable' releases, the legacy branch will no longer receive regular updates.

See the release overview on main NetworkManager page to find out which branch is which. The release branches are named 'nm-<major>-<minor>'.


Stable versions always end with an even number (eg, 0.9.6,, or 1.22), while development versions always end with an odd number (eg, 0.9.7 or 1.23). When releasing beta or RC versions, typically a large number is used as the micro version, eg to ensure that it is much larger than any previous version, and to indicate that we are close to release. This is less confusing than calling a "release candidate", even though we shouldn't read too much into version numbers. Some examples:

  • and 1.10.0 would both be stable releases
  • and 1.11.1 would be a development release on the way to a new "stable" series
  • and 1.11.95 would both be "beta" development releases on the way to 0.9.10 and 1.12, respectively
  • and 1.11.97 would both be "rc" development releases very close to the final 0.9.10 and 1.12 releases, respectively

Release Checklist

  • All components (ie, NM, nm-applet, and the VPN plugins) must pass 'git pull; make clean; make; make distcheck' on both i686 and x86-64 architectures

    • If a Big Endian architecture or a non-Intel/AMD platform is available (eg, PPC or ARM), ensure 'git pull; make clean; make; make distcheck' passes on that platform as well

  • All system settings plugins must pass 'make clean; make; make check' on i686 and x86-64 architectures, using the following process. This ensures that if we forget to enable a plugin at configure-time, we don't allow it to stay broken for a release because we didn't check it.

    • for plugin in [example, ifcfg-rh, ifcfg-suse, ifnet, ifupdown] do;

      • cd $plugin; make clean; make; make check

  • Complete basic smoketesting

  • Ensure that any new API has Since: tags added in the code documentation, and (for 0.9.10 and later) has an appropriate NM_AVAILABLE_IN_* annotation in the header file.

    • You can diff libnm-util.ver, libnm-glib.ver, and libnm.ver against the previous release to see all newly-added API.

    • In libnm.ver, all new API should be in a new section for this release, not added to an existing section.

  • Ensure documentation is updated by doing the following:
    • cd docs

    • make clean

    • make

    • fix any trivial warnings (argument name mismatches, undocumented functions, etc)
  • Fix any obvious errors in GObject Introspection data:
    • for dir in [libnm-util, libnm-glib, libnm] do;

      • make clean

      • make

      • inspect g-ir-scanner output for trivial errors and fix them

  • Ensure that libnm-util, libnm-glib, libnm-glib-vpn, and libnm sonames are bumped appropriately if API was added or changed

    • Follow the libtool version info rules

    • Triple-check the old soname and the new soname and make sure the changes are sane (libtool versioning is confusing!)
  • If this is a new stable release, update NM_VERSION_CUR_STABLE in libnm-core/ and libnm-util/, and add a new set of version macros for the next stable release. On master (but not the release branch), change NM_VERSION_NEXT_STABLE to be the next release.

  • Ensure that NEWS is updated for each component based on the git changelog, for notable or large changes. Trivial stuff like very small bug fixes don't really need to be mentioned.
  • Ensure that the version numbers in NetworkManager's are updated

    • should be the last commit before release, and follow the form "release: bump version to XXXX"
  • Ensure that the NM version dependency in in nm-applet and the VPN plugins matches the new NM version

  • Ensure that NM_VERSION_MIN_REQUIRED in in nm-applet and the VPN plugins is set to the same thing as in their
  • Ensure that NM_VERSION_MAX_ALLOWED is set to a future version in the same series. eg, for NetworkManager-vpnc 1.2.0, NM_VERSION_MAX_ALLOWED should be something like NM_VERSION_1_2_10 to ensure that it can be built against newer NM for a while without complaining.

  • Ensure that the version numbers in in nm-applet and the VPN plugins are updated, if necessary

    • should be the last commit before release, and follow the form "release: bump version to XXXX"
  • Tag the "release: bump version to XXXX" commit with the various version numbers:
    • micro - eg, (always specify a 'micro', as this prevents packaging problems when we do the next micro release; here the micro number is "0"); this tag must match the version in the "release: xxxxx" commit
    • friendly, if it's a development version - eg if the 'micro' version is or thereabouts, the friendly tag would be something like 0.9.6-rc1; we don't need a friendly release tag for an actual "final" release like or 1.12.0. The friendly tag helps out distros like Debian and Ubuntu who typically use package names/versions that include these types of release names.
    • NOTE: use annotated or signed tags, eg "git tag -s XXX" or the tag will be rejected when you push

  • Run 'make distclean; autogen <options>; make; make distcheck' in all components again to generate final release tarballs

  • 'git push' the repo

  • 'git push --tags' to ensure the tags get pushed too

  • Upload tarballs to
  • Run 'ftpadmin install' for all tarballs on

  • Ensure the new tarballs show up at (happens after a short delay)

  • Add the new release version to the appropriate bugzilla components; we only need to do this for actual stable releases like 0.9.6, don't bother with micro releases like
  • Mail release announcements to and any other appropriate lists

  • Bump the version numbers in to development versions

    • should be the first commit after the release, and follow the form "release: bump version to XXXX"

Projects/NetworkManager/ReleaseProcess (last edited 2016-02-11 09:16:05 by LubomirRintel)