HOWTO-RELEASE
1
HOWTO-RELEASE:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Notes on releasing.
0. Make sure that you have current FSF releases of autoconf, automake,
and libtool packages installed under a common installation prefix
and that these tools are in your executable search path prior to
any other installed versions. Versions delivered with Linux may be
altered so it is best to install official FSF releases. GNU 'm4'
1.4.16 is needed in order to avoid bugs in m4. These packages may
be downloaded from the following ftp locations:
m4 - ftp://ftp.gnu.org/pub/gnu/m4
autoconf - ftp://ftp.gnu.org/pub/gnu/autoconf
automake - ftp://ftp.gnu.org/pub/gnu/automake
libtool - ftp://ftp.gnu.org/pub/gnu/libtool
It is recommended to install m4 before autoconf, since the later
requires the former.
Release builds should only be done on a system with a functioning
and correctly set system clock and on a filesystem which accurately
records file update times. Use of GNU make is recommended.
25
1. Commit any unsaved changes.
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2. Use gnulib's gitlog-to-changelog script to add new (since the last
release) entries to the traditional ChangeLog file. Take note of
the most recent change note time stamp and use that as the starting
point. Concatenate the old logs to the new logs. The added logs
may be used to help produce the release notes (in next step). For
example:
gitlog-to-changelog --since=`head -n 1 ChangeLog | sed -e 's/ .*//g'` --append-dot > ChangeLog.added
printf "\n" >> ChangeLog.added
cat ChangeLog.added ChangeLog > ChangeLog.new
mv ChangeLog.new ChangeLog
rm ChangeLog.added
3. Create html/vX.X.html and add it to git with 'git add html/vX.X.html'.
Take ChangeLog entries and html-ify in there.
42
43
Easist thing to do is take html/vX.(X-1).html and use it as a template.
44
4. Add vX.X.html file to the list of 'docfiles' files in the html/Makefile.am.
46
5. Update html/index.html to refer to this new page as the current release.
48
6. Increment the release version in configure.ac. Put 'alpha' or
49
50
51
52
53
54
55
56
57
'beta' after the version, if applicable. For example:
4.0.0
or
4.0.0beta7
Version should be updated in two places: in the second argument of the
AC_INIT macro and in LIBTIFF_xxx_VERSION variables.
58
7. Update library ELF versioning in configure.ac (LIBTIFF_CURRENT,
59
60
61
62
63
64
65
66
67
68
LIBTIFF_REVISION, and LIBTIFF_AGE). These numbers have nothing to
do with the libtiff release version numbers.
Note that as of libtiff 4.X, proper ELF versioning is used so
please follow the rules listed in configure.ac. At a bare minimum,
you should increment LIBTIFF_REVISION for each release so that
installed library files don't overwrite existing files. If APIs
have been added, removed, or interface structures have changed,
then more care is required.
69
8. Add an entry to Changelog similar to:
70
71
72
* libtiff 4.0.0 released.
73
9. In the source tree do
74
75
76
77
78
79
80
./autogen.sh
This step may be skipped if you have already been using a
maintainer build with current autoconf, automake, and libtool
packages. It is only needed when updating tool versions.
81
10. It is recommended (but not required) to build outside of the source
82
83
84
85
86
87
88
89
90
91
92
93
tree so that the source tree is kept in a pristine state. This
also allows sharing the source directory on several networked
systems. For example:
mkdir libtiff-build
cd libtiff-build
/path/to/libtiff/configure --enable-maintainer-mode
otherwise do
./configure --enable-maintainer-mode
94
11. In the build tree do
95
96
97
98
99
100
make release
This will update "RELEASE-DATE", "VERSION", and libtiff/tiffvers.h
in the source tree.
101
12. In the source tree, verify that the version info in RELEASE-DATE,
102
103
VERSION and libtiff/tiffvers.h is right.
104
13. In the build tree do
105
106
107
108
109
110
111
112
113
114
make
make distcheck
If 'make distcheck' fails, then correct any issues until it
succeeds.
Two files with names tiff-version.tar.gz and tiff-version.zip will
be created in the top level build directory.
115
14. In the source tree do
117
'git status', 'git add .', 'git commit' and 'git push'
119
15. In the source tree, create a signed tag
121
git tag -s v4.0.0 -m "Create tag for v4.0.0"
122
123
124
(or the appropriate name for the release)
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
and push it to "origin" (if "origin" points to the official repository)
git push origin v4.0.0
16. Sign the release files in the build tree using your private key
export GPG_TTY=$(tty)
for file in tiff-*.tar.gz tiff-*.zip ; do \
gpg2 --output ${file}.sig --detach-sig $file ; \
done
for file in tiff-*.tar.gz tiff-*.zip ; do \
gpg2 --verify ${file}.sig $file ; \
done
17. Copy release packages from the build tree to the
141
142
143
ftp.remotesensing.org ftp site.
scp tiff-*.tar.gz tiff-*.zip \
144
bfriesen@upload.osgeo.org:/osgeo/download/libtiff
146
18. Announce to list, tiff@lists.maptools.org