From: Simon McVittie Date: Sat, 23 Jul 2022 10:19:28 +0000 (+0100) Subject: Move release checklist to its own file X-Git-Tag: dbus-1.15.0~19 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3758e5b1648a26fd2343db3c804d32a29ae75ff8;p=thirdparty%2Fdbus.git Move release checklist to its own file In other projects I've found that having a separate file that only lists the release steps makes them easier to check. Signed-off-by: Simon McVittie --- diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 96413c0b2..fb1634525 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -274,86 +274,7 @@ This section is not directly relevant to infrequent contributors. ### Releasing -To make a release of D-Bus, do the following: - - - check out a fresh copy from Git - - - verify that the libtool versioning/library soname is - changed if it needs to be, or not changed if not - - - update the file NEWS based on the git history - - - verify that the version number of dbus-specification.xml is - changed if it needs to be; if changes have been made, update the - release date in that file - - - update the AUTHORS file with "make update-authors" if necessary - - - the version number should have major.minor.micro, even - if micro is 0, i.e. "1.0.0" and "1.2.0" not "1.0"/"1.2"; the micro - version should be even for releases, and odd for intermediate snapshots - - - "make distcheck" (DO NOT just "make dist" - pass the check!) - - - if make distcheck fails, fix it. - - - once distcheck succeeds, "git commit -a". This is the version - of the tree that corresponds exactly to the released tarball. - - - tag the tree with "git tag -s -m 'Released X.Y.Z' dbus-X.Y.Z" - where X.Y.Z is the version of the release. If you can't sign - then simply created an unsigned annotated tag: - "git tag -a -m 'Released X.Y.Z' dbus-X.Y.Z". - - - bump the version number up in configure.ac (so the micro version is odd), - and commit it. Make sure you do this *after* tagging the previous - release! The idea is that git has a newer version number - than anything released. Similarly, bump the version number of - dbus-specification.xml and set the release date to "(not finalized)". - - - merge the branch you've released to the chronologically-later - branch (usually "master"). You'll probably have to fix a merge - conflict in configure.ac (the version number). - - - push your changes and the tag to the central repository with - git push origin master dbus-X.Y dbus-X.Y.Z - - - scp your tarball to freedesktop.org server and copy it to - dbus.freedesktop.org:/srv/dbus.freedesktop.org/www/releases/dbus/dbus-X.Y.Z.tar.xz. - This should be possible if you're in group "dbus" - - - Update the online documentation with `make -C doc maintainer-upload-docs`. - - - update the wiki page http://www.freedesktop.org/Software/dbus by - adding the new release under the Download heading. Then, cut the - link and changelog for the previous that was there. - - - post to dbus@lists.freedesktop.org announcing the release. - -### Making a ".0" stable release - -We create a branch for each stable release. The branch name should be -dbus-X.Y which is a branch that has releases versioned X.Y.Z; -changes on a stable branch should be limited to significant bug fixes. - -Because we won't make minor changes like keeping up with the latest -deprecations on a stable branch, stable branches should turn off the -gcc warning for deprecated declarations (e.g. see commit 4ebb275ab7). - -Be extra-careful not to merge master (or any branch based on master) into a -stable branch. - -To branch: - - git branch dbus-X.Y - -and upload the branch tag to the server: - - git push origin dbus-X.Y - -To develop in this branch: - - git checkout dbus-X.Y +See maint/release-checklist.md. ### Code reviews diff --git a/maint/release-checklist.md b/maint/release-checklist.md new file mode 100644 index 000000000..5de87933d --- /dev/null +++ b/maint/release-checklist.md @@ -0,0 +1,82 @@ +# dbus release checklist + +To make a release of D-Bus, do the following: + + - check out a fresh copy from Git + + - verify that the libtool versioning/library soname is + changed if it needs to be, or not changed if not + + - update the file NEWS based on the git history + + - verify that the version number of dbus-specification.xml is + changed if it needs to be; if changes have been made, update the + release date in that file + + - update the AUTHORS file with "make update-authors" if necessary + + - the version number should have major.minor.micro, even + if micro is 0, i.e. "1.0.0" and "1.2.0" not "1.0"/"1.2"; the micro + version should be even for releases, and odd for intermediate snapshots + + - "make distcheck" (DO NOT just "make dist" - pass the check!) + + - if make distcheck fails, fix it. + + - once distcheck succeeds, "git commit -a". This is the version + of the tree that corresponds exactly to the released tarball. + + - tag the tree with "git tag -s -m 'Released X.Y.Z' dbus-X.Y.Z" + where X.Y.Z is the version of the release. If you can't sign + then simply created an unsigned annotated tag: + "git tag -a -m 'Released X.Y.Z' dbus-X.Y.Z". + + - bump the version number up in configure.ac (so the micro version is odd), + and commit it. Make sure you do this *after* tagging the previous + release! The idea is that git has a newer version number + than anything released. Similarly, bump the version number of + dbus-specification.xml and set the release date to "(not finalized)". + + - merge the branch you've released to the chronologically-later + branch (usually "master"). You'll probably have to fix a merge + conflict in configure.ac (the version number). + + - push your changes and the tag to the central repository with + git push origin master dbus-X.Y dbus-X.Y.Z + + - scp your tarball to freedesktop.org server and copy it to + dbus.freedesktop.org:/srv/dbus.freedesktop.org/www/releases/dbus/dbus-X.Y.Z.tar.xz. + This should be possible if you're in group "dbus" + + - Update the online documentation with `make -C doc maintainer-upload-docs`. + + - update the wiki page http://www.freedesktop.org/Software/dbus by + adding the new release under the Download heading. Then, cut the + link and changelog for the previous that was there. + + - post to dbus@lists.freedesktop.org announcing the release. + +## Making a ".0" stable release + +We create a branch for each stable release. The branch name should be +dbus-X.Y which is a branch that has releases versioned X.Y.Z; +changes on a stable branch should be limited to significant bug fixes. + +Because we won't make minor changes like keeping up with the latest +deprecations on a stable branch, stable branches should turn off the +gcc warning for deprecated declarations (e.g. see commit 4ebb275ab7). + +Be extra-careful not to merge master (or any branch based on master) into a +stable branch. + +To branch: + + git branch dbus-X.Y + +and upload the branch tag to the server: + + git push origin dbus-X.Y + +To develop in this branch: + + git checkout dbus-X.Y