forked from mathstuf/gdal-svn
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathHOWTO-RELEASE
161 lines (109 loc) · 5.65 KB
/
HOWTO-RELEASE
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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
Notes on Preparing a GDAL Source Release
========================================
Prerequisites:
1) Check that the release is ready to go as far as ABI (binary compatibility)
is concerned. This can be checked by comparing the installed headers of the
candidate release with the installed headers of the previous release
(diff -ur $(OLD_INSTALL_DIR)/include $(NEW_INSTALL_DIR)/include). The API
is defined as all functions and classes exported by the CPL_DLL keyword.
- For major and minor releases, there must be no function signature change
for the C API. Only new functions are allowed.
- For major releases, the allowed changes in C++ API should (or must?) be
such that user calling C++ code can still compile against new headers
without modification (existing methods can become virtual, default
arguments can be added, new methods or members can be added)
- For minor releases (1.6.1 versus 1.6.0), the C++ ABI stability must be
preserved : no method signature change, no addition of virtual methods, no
new members. Only non-virtual methods can be added.
It may also be helpful to check:
http://upstream-tracker.org/versions/gdal.html
Process :
1) a) Regenerate configure using autogen.sh and commit if changed.
b) Regenerate swig generated files for python bindings and commit if changed.
There is often a reference system on which this should be done (ie. Frank's
dev workstation) to avoid unnecessary churn from different autoconf or swig
versions.
2) Update the release date, and number information in gcore/gdal_version.h.
3) Update the VERSION file.
3.1) Update ./swig/python/setup.py version information.
And the version of libgdal in ./swig/python/README.txt
3.2) Update ./swig/include/perl/gdal_perl.i $VERSION and $GDAL_VERSION
strings to current version. Kick Perl module maintainer to make a CPAN
release.
3.3) For major releases update the VERSION macro in nmake.opt (for 1.6, 1.7etc)
4) Update LIBGDAL_CURRENT/REVISION/AGE macros in GDALmake.opt.in.
- For a release with no interface changes just bump REVISION.
- Adding interfaces, bump CURRENT/AGE, set REVISION to 0.
- Deleting interfaces / compatibility issues - bump CURRENT, others to zero.
5) Prepare release overview in the NEWS file. The Trac revision log for
trunk or the stable branch can be helpful.
http://trac.osgeo.org/gdal/log/branches/1.4
- commit new version to NEWS file.
6) Update the GDAL http://trac.osgeo.org/gdal/wiki/DownloadSource topic to
refer to the latest available source.
Update http://trac.osgeo.org/gdal/wiki (Releases section)
Update http://trac.osgeo.org/gdal/wiki/NewsAndStatus
7) If this is a major release, prepare a branch.
svn copy https://svn.osgeo.org/gdal/trunk \
https://svn.osgeo.org/gdal/branches/1.5
8) Tag the release set in SVN:
svn copy https://svn.osgeo.org/gdal/branches/1.4 \
https://svn.osgeo.org/gdal/tags/1.4.1
9) Create the source distributions using the mkgdaldist.sh script. The
argument should be the version number (ie. 1.4.1).
eg.
% mkgdaldist.sh 1.4.0
or
% mkgdaldist.sh 1.4.2 -branch tags/1.4.2
10) Create a snapshot of the documentation.
ie. On www.gdal.org:
% cd /osgeo/gdal
% ./gdal-web-refresh.sh
% zip -r gdal180doc.zip gdal-web/*.* gdal-web/ogr gdal-web/java
11) Create a snapshot of autotest suite:
svn export http://svn.osgeo.org/gdal/branches/1.6/autotest gdalautotest-1.6.0
tar czvf gdalautotest-1.6.0.tar.gz gdalautotest-1.6.0
zip -r gdalautotest-1.6.0.zip gdalautotest-1.6.0
11.5) If changes have been made in the frmts/grass or ogr/ogrsf_frmts/grass dir,
generate an up-to-date gdal-grass snapshot (let's not forget do it for GDAL 1.7.0 !):
% cd frmts/grass
% make dist
12) Publish the resulting files in download.osgeo.org/gdal/X.Y.Z (where X.Y.Z is the version number)
and add a symlink from X.Y.Z to CURRENT (except for stable releases in a "old" branch).
% ln -sf X.Y.Z CURRENT
13) Announce release to :
- bugfix release: [email protected], [email protected]
14) Update the freecode.com (previously freshmeat) entry for GDAL.
15) Update the freegis.org entry for GDAL.
16) Update doc/index.dox to advertize the new release and link to the release notes
17) Create a News page in Trac for the release (like
http://trac.osgeo.org/gdal/wiki/Release/1.7.0-News) and reference it from
http://trac.osgeo.org/gdal/ (Releases) and
http://trac.osgeo.org/gdal/wiki/NewsAndStatus .
18) Add pointers to the source releases at:
http://trac.osgeo.org/gdal/wiki/DownloadSource
19) Update Trac to mark this release milestone as "Completed", and create
a corresponding version. Then create a new milestone for the next release.
20) Upload the new Python bindings to Pypi (requires upload rights to
the GDAL package by one of the current owners : HowardB/FrankW/EvenR)
( procedure taken from http://peterdowns.com/posts/first-time-with-pypi.html )
a) Create a $HOME/.pypirc file :
[distutils] # this tells distutils what package indexes you can push to
index-servers = pypi
pypitest
[pypi] # authentication details for live PyPI
repository: https://pypi.python.org/pypi
username: yourlogin
password: yourpassword
[pypitest] # authentication details for test PyPI
repository: https://testpypi.python.org/pypi
username: yourlogin
password: yourpassword
b) cd swig/python
c) For trial :
python setup.py register -r pypitest
python setup.py sdist upload -r pypitest
d) For real :
python setup.py register -r pypi
python setup.py sdist upload -r pypi