- 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
- 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.
+ 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
- post to dbus@lists.freedesktop.org announcing the release.
-After making a ".0" stable release
+Making a ".0" stable release
===
-We create a branch for each stable release; sometimes the branch is
-not done immediately, instead it's possible to wait until someone has
-a not-suitable-for-stable change they want to make and then branch to
-allow committing that change.
+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).
-The branch name should be dbus-X.Y which is a branch that has
-releases versioned X.Y.Z
+Be extra-careful not to merge master (or any branch based on master) into a
+stable branch.
To branch:
git branch dbus-X.Y
- if there's a live unresolved controversy about a change,
don't commit it while the argument is still raging.
+ - at their discretion, members of the reviewer group may also commit
+ branches/patches under these conditions:
+
+ - the branch does not add or change API, ABI or wire-protocol
+
+ - the branch solves a known problem and is covered by the regression tests
+
+ - there are no objections from the rest of the review group within
+ a week of the patches being attached to Bugzilla
+
+ - the committer gets a positive review on Bugzilla from someone they
+ consider qualified to review the change (e.g. a colleague with D-Bus
+ experience; not necessarily a member of the reviewer group)
+
- regardless of reviews, to commit a patch:
- make check must pass
- the test suite must be extended to cover the new code
Scott James Remnant <scott@netsplit.com>
Will Thompson <will.thompson@collabora.co.uk>
Simon McVittie <simon.mcvittie@collabora.co.uk>
-
-
+David Zeuthen <davidz@redhat.com>