1
Subversion Tarball Release Procedure
2
====================================
4
1. When starting a new major or minor line create a release branch
5
from the "golden" revision number (otherwise skip to step 3):
7
svn cp -rHEAD -m"Create release X.Y.Z branch" \
8
https://svn.collab.net/repos/svn/trunk \
9
https://svn.collab.net/repos/svn/branches/X.Y.x
11
All release of the X.Y line will come out of this branch.
12
Changes from trunk will be merged based upon compatibility
13
rules and voting as explained in HACKING.
15
2. Bump the version numbers in svn_version.h on trunk.
17
Note that this should be the next major/minor line we plan on doing.
18
E.G. if you're making the 1.1.x branch then the svn_version.h in trunk
21
You'll commit this change along with the change in step 3.
23
3. Tweak trunk to have a new CHANGES section.
25
a) Begin a new section at the top of the CHANGES file with:
27
Version X.Y.Z (released XX Month 200X, from branches/X.Y.Z)
28
http://svn.collab.net/repos/svn/tags/X.Y.Z
32
4. Create a working copy (wc) from the release branch:
34
$ svn co https://svn.collab.net/repos/svn/branches/X.Y.Z
36
5. Merge fixes and changes from trunk.
38
Only very important bugfixes are allowed to merge from the trunk to
39
the release branch. A decision of a merge happends in the STATUS
40
file as documented in HACKING.
42
In the following example, we pretends to merge revision 7868 into
45
a) cd to your branch release working copy and run:
47
$ svn merge -r7867:7868 https://svn.collab.net/repos/svn/trunk
49
b) Commit the changes:
51
$ svn ci -m "Merge r7868 into the 0.34.0 branch"
53
c) cd to your wc for https://svn.collab.net/repos/svn/trunk and add
54
a note under User-visible changes or Developer-visible changes.
56
* fixed: Java bindings compilation.
58
Differentiate between client-side and server-side changes by,
59
say, putting them in separate sections. (We don't currently
60
have an example of this, but we intend to do it for future
63
Note: CHANGES is maintained on the trunk because future releases should
64
have past releases CHANGES entries. It will be merged onto the branch
65
just before a release.
69
6. It's release time, so cd to the release branch's working copy.
71
Make sure your release branch wc has the following packages
72
extracted into the root of the wc tree:
74
apr (see INSTALL, section I)
75
apr-util (see INSTALL, section I)
76
neon (see INSTALL, section I)
78
To install apr/apr-util, see INSTALL, section I.1.
80
To install neon, see INSTALL, section I.5.
82
To configure/install Apache (httpd-2.X.YY), see INSTALL,
83
section I.7 and section III. If you maintain a separate
84
build/release area, and don't want to over-write an
85
existing/working installation of Apache, you may want to use
86
--prefix=/usr/local/apache2 to install a parallel instance of
89
To make sure httpd.conf is properly set up for DAV access, see
90
subversion/tests/clients/cmdline/README.
92
You should also have libtool-1.5.10 and autoconf-2.59 installed
93
from source. It is important that you do not use distribution
94
shipped versions of this software as they are often patched in
95
ways that are not portable.
97
Also, see sections 'Building the Latest Source under Unix' and
98
'BUILDING A SUBVERSION SERVER' in the INSTALL file. for more
99
detailed build information.
101
When building the Windows .zip release be sure to use the apr files
102
from the .zip packaging of Apache. Additionally you'll want to
103
also include the apr-iconv directory from right next to apr-util in
104
the Apache zip file. See INSTALL, section I.1, for details.
106
7. Merge CHANGES into the release branch. Do it the same way as described in
107
section 4 in this document when merging fixes to the release branch.
109
8. Build the tarballs and zip file
111
a) Run './dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z'
113
Watch dist.sh's output to make sure everything goes smoothly; when
114
it's done, you'll have 'subversion-X.Y.Z.tar.gz' and
115
'subversion-X.Y.Z.tar.bz2' in the cwd.
117
b) Be sure to replace the apr, apr-util and apr-iconv dirs with the
118
ones from the .zip packaging of Apache, before building the .zip,
119
as mentioned above in 6.
121
c) Run './dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z -zip'
123
Again watch dist.sh's output to make sure everything goes smoothly;
124
when it's done, you'll have 'subversion-X.Y.Z.zip' in the cwd.
126
9. Test one or both of the tarballs:
127
a) tar zxvf subversion-X.Y.Z.tar.gz; cd subversion-X.Y.Z
130
See INSTALL, section III.B for detailed instructions
131
on configuring/building Subversion.
133
If you installed Apache in some place other than the default, as
134
mentioned above, you will need to use the same
135
--prefix=/usr/local/apache2 option as used to configure Apache.
137
You may also want to use --enable-mod-activation, which will
138
automatically enable the required Subversion modules in the
143
e) make install (this activates mod_dav)
146
For this, start up Apache after having configured according to
147
the directions in subversion/tests/clients/cmdline/README.
149
Make sure, that if you maintain a development installation of
150
apache, that you check the config file and update it for the
151
new release area where you're testing the tar-ball.
153
(Unless you rename the tree which gets extracted from the
154
tarball to match what's in httpd.conf, you will need to edit
159
First, start up svnserve with these args:
161
$ subversion/svnserve/svnserve -d -r \
162
`pwd`/subversion/tests/clients/cmdline
164
-d tells svnserve to run as a daemon
165
-r tells svnserve to use the following directory as the
166
logical file system root directory.
168
After svnserve is running as a daemon 'make svncheck' should run
170
h) Then test that you can check out the subversion repository
171
with this environment:
173
subversion/clients/cmdline/svn co \
174
https://svn.collab.net/repos/svn/trunk
176
i) Verify that the perl and python swig bindings at least compile.
177
If you can't do this, then have another developer verify.
179
(see bindings/swig/INSTALL for details)
181
Ensure that ./configure detected a suitable version of swig,
182
perl, and python. Then:
185
sudo make install-swig-py
189
sudo make install-swig-pl
191
j) Verify that the javahl bindings at least compile.
192
If you can't do this, then have another developer verify.
194
(see bindings/java/javahl/README for details)
196
Ensure that ./configure detected a suitable jdk, and then
197
possibly re-run with '--enable-javahl' and '--with-jdk=':
200
sudo make install-javahl
203
10. Use GPG to sign release.
205
gpg -b --armor subversion-X.Y.Z.tar.gz
206
gpg -b --armor subversion-X.Y.Z.tar.bz2
207
gpg -b --armor subversion-X.Y.Z.zip
209
11. Upload the tarballs to http://subversion.tigris.org/tarballs/.
211
The RM will be given details on how to do this via private channels.
213
12. Link to the tarballs from the Downloads page:
215
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=260
219
a. Log into http://subversion.tigris.org/
220
b. Click on the 'Downloads link (left frame at the top)
221
c. Click on the 'Source tarballs' link (main frame)
222
d. Click on the 'Add a file' link (top, main frame, under 'File Sharing')
223
e. Fill in the following fields:
225
Name: subversion-X.Y.Z.tar.gz (replace X.Y.Z with the release number)
227
Description: Subversion release X.Y.Z (MD5: <md5sum of tarball>)
228
Contents: (choose 'Link', then enter
229
http://subversion.tigris.org/tarballs/subversion-X.Y.Z.tar.gz)
233
12. Create the tag with the svn_version.h that reflects the final release.
234
You do this by updating your working copy to the release revision, 1234 in
235
the example below. Run svnversion to verify that you do not have a mixed
236
working copy or modified working copy, i.e. svnversion outputs only the
237
release revision (not 1234:1235 or 1234M). Then place the svn_version.h.dist
238
file in place in the working copy and copy from the working copy to the tag
245
cp svn_version.h.dist subversion/include/svn_version.h
246
svn cp -m "Tagging release X.Y.Z with svn_version.h matching tarball" \
247
. https://svn.collab.net/repos/svn/tags/X.Y.Z
249
Note: Please always make a tag, even for release candidates.
251
13. Bump the svn_version.h for the original branch.
253
Modify subversion/include/svn_version.h
254
If you just did 1.0.2 then svn_version.h should have the proper
255
values for 1.0.3 and so on.
257
14. Update the website.
259
a) Edit the www/project_status.html file appropriately in /trunk *NOT*
260
in the release branch and commit. Remember edit a search term at the
261
end of release's issue link.
263
If you used 'svn switch' in 3b above, you can simply 'switch' back
266
svn switch https://svn.collab.net/repos/svn/trunk
268
then edit the www/project_status.html file appropriately.
270
b) Update the best available version at the top of www/project_packages.html
272
c) Commit the modifications.
274
15. Post news item <http://subversion.tigris.org/servlets/ProjectNewsAdd>,
275
and send an announcement to dev@, users@, and announce@ lists.
276
Remember to include the URL and MD5 checksum in the announcement.
278
Also notify freshmeat of the new release.
280
16. Someone with administrative access should upgrade svn.collab.net
281
to head. (This is not usually the release manager.)
added
removed
notes/releases.txt
