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
177
178
179
180
181
182
183
184
185
186
187
188
189
|
# Release checklist:
## Pre-release tasks
* Figure out whether a release is worthwhile to do.
* Analyze the previous release branch to see if anything should have been
applied to master.
* Collect changes and assemble tentative release notes.
* Identify previous release branch point
* Check commit logs between previous branch point and now for
notable changes worth mentioning
* Create a new issues_closed_for_X.Y.md file
* Include notable entries from here in the release notes.
* Analyze APIs between previous release branch and master to produce list of
changes (added/removed/updated funcs, etc...), and detect backwards compat
issues.
* https://github.com/lvc/abi-compliance-checker
* See also `abi-check.sh`
* If the new release is not backwards compatible, then this is a MAJOR release.
* Mention removed features in ChangeLog
* Consider re-adding backwards compatible support, through symbol
aliases and appropriate entries in json-c.sym
* Be sure any new symbols are listed in json-c.sym as part of
the _new_ release version.
* Update the AUTHORS file
PREV=$(git tag | tail -1)
( git log -r ${PREV}..HEAD | grep Author: | sed -e's/Author: //' ; cat AUTHORS ) | sort -u > A1
mv A1 AUTHORS
* Exclude mentioning changes that have already been included in a point
release of the previous release branch.
* Update ChangeLog with relevant notes before branching.
* Check that the compile works on Linux - automatic through Travis
* Check that the compile works on NetBSD
* Check that the compile works on Windows - automatic through AppVeyor
## Release creation
Start creating the new release:
PREV=$(git tag | tail -1)
PREV=${PREV#json-c-}
PREV=${PREV%-*}
release=0.$((${PREV#*.} + 1))
cd ~
git clone https://github.com/json-c/json-c json-c-${release}
rm -rf distcheck
mkdir distcheck
cd distcheck
# Note, the build directory *must* be entirely separate from
# the source tree for distcheck to work properly.
cmake -DCMAKE_BUILD_TYPE=Release ../json-c-${release}
make distcheck
cd ..
Make any fixes/changes *before* branching.
cd json-c-${release}
git checkout -b json-c-${release}
------------
Using ${release}:
Update the version in json_c_version.h
Update the version in CMakeLists.txt (VERSION in the project(...) line)
Update the set_target_properties() line in CmakeLists.txt to set the shared
library version. Generally, unless we're doing a major release, change:
VERSION x.y.z
to
VERSION x.y+1.z
git commit -a -m "Bump version to ${release}"
If we're doing a major release (SONAME bump), also bump the version
of ALL symbols in json-c.sym.
See explanation at https://github.com/json-c/json-c/issues/621
More info at: https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf
------------
Generate the doxygen documentation:
(cd ../distcheck && make doc)
cp -r -p ../distcheck/doc/{html,Doxyfile} doc/.
rm doc/Doxyfile # Remove generated file w/ hardcoded paths
git add -f doc
git commit doc -m "Generate docs for the ${release} release"
------------
Create the release tarballs:
cd ..
echo .git > excludes
tar -czf json-c-${release}.tar.gz -X excludes json-c-${release}
echo 'doc/*.cmake' >> excludes
echo 'doc/CMakeFiles' >> excludes
echo 'doc/Makefile' >> excludes
echo 'doc/Doxyfile' >> excludes
echo 'doc/html' >> excludes
tar -czf json-c-${release}-nodoc.tar.gz -X excludes json-c-${release}
------------
Tag the branch:
cd json-c-${release}
git tag -a json-c-${release}-$(date +%Y%m%d) -m "Release json-c-${release}"
git push origin json-c-${release}
git push --tags
------------
Go to Amazon S3 service at:
https://console.aws.amazon.com/s3/
Upload the two tarballs in the json-c_releases/releases folder.
* Expand "Permissions", pick "Grant public-read access"
* Expand "Properties", ensure "Standard" storage class is picked.
Logout of Amazon S3, and verify that the files are visible.
https://s3.amazonaws.com/json-c_releases/releases/index.html
===================================
Post-release checklist:
git checkout master
Add new section to ChangeLog for ${release}+1
Use ${release}.99 to indicate a version "newer" than anything on the branch:
Update the version in json_c_version.h
Update the version in CMakeLists.txt
Update the set_target_properties() line in CmakeLists.txt to match the release branch.
Add a new empty section to the json-c.sym file, for ${release}+1
git commit -a -m "Update the master branch to version ${release}.99"
git push
------------
Update the gh-pages branch with new docs:
cd json-c-${release}
git checkout json-c-${release}
cd ..
git clone -b gh-pages https://github.com/json-c/json-c json-c-pages
cd json-c-pages
mkdir json-c-${release}
cp -R ../json-c-${release}/doc json-c-${release}/.
git add json-c-${release}
rm json-c-current-release
ln -s json-c-${release} json-c-current-release
git commit -a -m "Add the ${release} docs."
vi index.html
# Add/change links to current release.
git commit -a -m "Update the doc links to point at ${release}"
git push
------------
Update checksums on wiki page.
cd ..
openssl sha -sha256 json-c*gz
openssl md5 json-c*gz
Copy and paste this output into the wiki page at:
* https://github.com/json-c/json-c/wiki
* https://github.com/json-c/json-c/wiki/Old-Releases
------------
Send an email to the mailing list.
|
