/
HOWTORELEASE.txt
176 lines (109 loc) · 5.08 KB
/
HOWTORELEASE.txt
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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
Steps for Making a PDAL Release
==============================================================================
:Author: Howard Butler
:Contact: howard@hobu.co
:Date: 04/04/2018
This document describes the process for releasing a new version of PDAL.
General Notes
------------------------------------------------------------------------------
Release Process
1) Increment Version Numbers
- CMakeLists.txt
* set(PDAL_VERSION_STRING "1.0.0" CACHE STRING "PDAL version")
* DISSECT_VERSION() CMake macro will break version down into
PDAL_VERSION_MAJOR, PDAL_VERSION_MINOR, PDAL_VERSION_PATCH,
and PDAL_CANDIDATE_VERSION strings.
- Update SO versioning
set(PDAL_API_VERSION "1")
set(PDAL_BUILD_VERSION "1.0.0")
* https://github.com/libspatialindex/libspatialindex/pull/44#issuecomment-57088783
- doc/quickstart.rst has a number of current-release references
- doc/download.rst point to new release
- appveyor.yml
- Make and push new release branch
::
git branch 1.7-maintenance
git push origin 1.7-maintenance
- Increment the doc build branch of .travis.yml:
"$TRAVIS_BRANCH" = "1.7-maintenance"
- Make DockerHub build entry for new release branch.
2) Write and update release notes. Use the PDAL "releases" section to create one.
Write the document in Markdown for convenience on GitHub.
- Manually store a copy of it in ./doc/development/release-notes/1.7.0.md
for future reference.
- Convert it to reStructuredText using pandoc and add the output to the
RELEASENOTES.txt document
::
pandoc --from markdown --to rst --output=1.7.rst doc/development/release-notes/1.7.0.md
3) Update ChangeLog with git2cl
* git2cl . > ChangeLog
* Delete any lines with "Merge" in them
::
git2cl . > Changelog
gsed -i '/Merge/d' ./ChangeLog
4) Build and run the tests. Really.
::
ctest -V
5) Clone a new tree and issue cmake. The package_source CMake target is
aggressive about scooping up every file in the tree to include in the package.
It does ok with CMake-specific stuff, but any other cruft in the tree is
likely to get dumped into the package.
::
git clone git://github.com/PDAL/PDAL.git pdal2
cmake .
6) Make the source distribution. If you are doing a release candidate
add an RC tag to the invocation.
::
./package.sh
./package.sh RC1
package.sh will rename the source files if necessary for the release
candidate tag and create .md5 sum files. This script only works on
linux and windows.
7) Update docs/download.txt to point at the location of the new release
8) Upload the new release to download.osgeo.org:/osgeo/download/pdal
::
scp PDAL-* hobu@download.osgeo.org:/osgeo/download/pdal
9) Tag the release. Use the ``-f`` switch if you are retagging because you
missed something.
::
git tag 1.0.0
git push --tags
10) Write the release notes. Email PDAL mailing list with notice about release
11) Upload new OSGeo4W package to download.osgeo.org:/osgeo/download/osgeo4w/x86_64/release/pdal
- Go to https://ci.appveyor.com/project/hobu/pdal
- Choose ``OSGEO4W_BUILD=ON`` build
- Scroll to very bottom
- Fetch tarball "OSGeo4W64 build will be uploaded to https://s3.amazonaws.com/pdal/osgeo4w/pdal-a4af2420b09725a4a0fff1ef277b1.7370c497d2.tar.bz2"
- rename to match current release and set OSGeo4W build number to 1
::
mv pdal-a4af2420b09725a4a0fff1ef277b1.7370c497d2.tar.bz2 pdal-1.7.0-1.tar.bz2
- copy to OSGeo4W server
::
scp pdal-1.7.0-1.tar.bz2 hobu@download.osgeo.org:/osgeo/download/osgeo4w/x86_64/release/pdal
- refresh OSGeo4W
::
http://upload.osgeo.org/cgi-bin/osgeo4w-regen.sh
- promote release
::
http://upload.osgeo.org/cgi-bin/osgeo4w-promote.sh
12) Update Alpine package
- The PDAL Alpine package lives at
https://github.com/alpinelinux/aports/blob/master/testing/pdal/APKBUILD.
Pull requests can be made against the alpinelinux/aports repository. If the
build configuration alone is changing, with no version increase, simply
increment the build number `pkgrel`. If the `pkgver` is changing, then
reset `pkgrel` to 0.
- Pull requests should have a commit message of the following form
`testing/pdal: <description>`.
13) Update Conda package
- For PDAL releases that bump version number, but do not change dependencies
or build configurations, the `regro-cf-autotick-bot` should automatically
create a pull request at https://github.com/conda-forge/pdal-feedstock.
Once the builds succeed, the PR can be merged and the updated package will
soon be available in the `conda-forge` channel. If the PR does not build
successfully, updates to the PR can be pushed to the bot's branch. Version
bumps should reset the build number to zero.
- Updates that alter the build configuration but do not bump the version
number should be submitted as PRs from a fork of the
https://github.com/conda-forge/pdal-feedstock repository. In these cases,
the build number should be incremented.