Hi Eric, I thought it would be more useful to document (semi-)publicly how I do upstream releases of libnbd / nbdkit. None of this is set in stone, it's just how I do it right now. For upstream development (master) branch dot releases: - Edit configure.ac and update the last field of AC_INIT - This should all pass: ./configure make distclean ./configure --enable-gcc-warnings --enable-python-code-style make make check make check-valgrind - This compares the files in the dist tarball with the files in git and is useful to make sure EXTRA_DIST isn't missing anything: make dist make maintainer-check-extra-dist - I usually copy the tarball to another machine to make sure it compiles. - Once you're happy the tarball works, commit & tag it: make maintainer-commit make maintainer-tag git push ; git push --tags - GPG sign the tarball with a detached signature and upload it to the website. (I will talk to you about this separately). Note that since the tarball contains generated files, especially for libnbd, we don't rely on the automatically generated tarballs in gitlab. For a Fedora Rawhide release, which usually follows from the above: - fedpkg clone -B libnbd # or nbdkit cd libnbd/rawhide - Edit libnbd.spec to set the updated version, and add a %changelog entry. See previous commits for examples. - Upload the sources: fedpkg new-sources libnbd-*.tar.gz libnbd-*.tar.gz.sig - Commit, push it and build: fedpkg commit -c fedpkg push fedpkg build #fedora update # only required on non-Rawhide branches Check the other Fedora branches. At the moment they are following the stable branch, only Rawhide follows the development branch. But at other times it is possible that a Fedora release branch might be following the development branch (because our upstream releases don't synchronise with Fedora). For an upstream stable branch (stable-1.xx) dot release: - Cherry pick only patches which are any of: * Bug fixes * Simple code refactoring that don't introduce new features. - Definitely don't introduce new features in the stable branch. - I try to avoid introducing new tests in the stable branch, because tests can fail and we don't want someone upgrading along the stable branch to have build issues. - I usually like to keep the commits in the same order as the development branch as much as possible, but it's not a hard requirement. - I find it very helpful to use git cherry-pick -x option since it makes it easy to search git log to see what commits have been backported (especially useful when commits depend on each other). - Proceed per development release as above. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/