forked from PDAL/PDAL
-
Notifications
You must be signed in to change notification settings - Fork 0
/
HOWTORELEASE.txt
129 lines (91 loc) · 4.83 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
Steps for Making a PDAL Release
==============================================================================
:Author: Howard Butler
:Contact: [email protected]
:Date: 04/04/2018
This document describes the process for releasing a new version of PDAL.
General Notes
------------------------------------------------------------------------------
Release Process
1) Make a release branch. Any changes you make to factilitate the release should be
made in the release branch.
::
git checkout -b 2.4-maintenance
git push -u origin 2.4-maintenance
2) Build and run the tests. Turn on all the optional bits that you have support for in
your cmake options..
::
mkdir build
cd build
cmake -G Ninja ..
ninja
ctest
3) If you have time, download or build the latest released Clang and GCC and fix any
bugs or warnings that show up. Run the tests. If you're really brave, do the same
thing with MSVC. Fix all warnings/problems.
4) Set Version Numbers. The only place you need to set the PDAL version number is in
the project() function of CMakeLists.txt.
- CMakeLists.txt
* project(PDAL VERSION 2.4.0 LANGUAGES CXX C)
- Update library version in CMakeLists.txt. Note that if there is no breaking ABI
change (unlikely), you can just update the minor version number.
set(PDAL_SOLIB_MAJOR 15)
set(PDAL_SOLIB_MINOR 0)
set(PDAL_SOLIB_BUILD 0)
- doc/download.rst point to new release
- Increment the doc build branch of .github/workflows/docs.yml:
if: github.ref == 'refs/heads/2.4-maintenance'
- Make DockerHub build entry for new release branch.
5) Write the `release notes. <https://github.com/PDAL/PDAL/releases/new>`_
- The safest way to do this is to go though all the commits since the last release
and reference any changes worthy of the release notes. See previous release notes
for a template and a starting point. If you find issues after making the release
branch, add them to the release notes.
- Manually store a copy of the release notes in ./doc/development/release-notes/2.4.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=2.4.rst doc/development/release-notes/2.4.0.md
6) Make the source distribution. If you are doing a release candidate
add an RC tag to the invocation. The version number is automatically picked out of the PDAL
release. The package is based on the current HEAD commit.
::
./package.sh
OR
./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) Unpack the built package source and check that it contains the files you expect and
none of the files you don't expect. Build the packaged source just as you would build
the source in a github branch.
8) Drag and drop each of the release files you built as part of the package process
into the github release you created earlier. Click on "Choose a tag" and enter
a new release tag (2.4.0RC1, for example). Set the "Target" branch to the maintenance
branch you created earlier (2.4-maintenance, for example). Choose "This is a pre-release"
if you're doing a release candidate. Press "Publish release".
9) Email PDAL mailing list with notice about release.
10) Merge the release branch into the main/master branch. Make sure both branches
are pushed to the origin repository.
11) 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.
12) [Optional] 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>`.