blob: 07e1067f6970c31183fa655b959ae953b9bd11bb (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
# 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
- remember to update **both** `configure.ac` **and** `meson.build`
- CMake takes the version number from `configure.ac` and so should not
need updating
- 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
- remember to update **both** `configure.ac` **and** `meson.build`
- CMake takes the version number from `configure.ac` and so should not
need updating
- "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` and `meson.build`
again (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
|
