|
cannam@147
|
1 How to release
|
|
cannam@147
|
2 ==============
|
|
cannam@147
|
3
|
|
cannam@147
|
4 **Developing**
|
|
cannam@147
|
5
|
|
cannam@147
|
6 * First, develop some new features to release! As you do, make sure to keep the documentation
|
|
cannam@147
|
7 up-to-date.
|
|
cannam@147
|
8
|
|
cannam@147
|
9 **Testing**
|
|
cannam@147
|
10
|
|
cannam@147
|
11 * Run `super-test.sh` on as many platforms as you have available. Remember that you can easily run
|
|
cannam@147
|
12 on any machine available through ssh using `./super-test.sh remote [hostname]`. Also run in
|
|
cannam@147
|
13 Clang mode. (If you are Kenton and running from Kenton's home machine and network, use
|
|
cannam@147
|
14 `./mega-test.py mega-test.cfg` to run on all supported compilers and platforms.)
|
|
cannam@147
|
15
|
|
cannam@147
|
16 * Manually test Windows/MSVC -- unfortunately this can't be automated by super-test.sh.
|
|
cannam@147
|
17
|
|
cannam@147
|
18 * Manually run the pointer fuzz tests under Valgrind. This will take 40-80 minutes.
|
|
cannam@147
|
19
|
|
cannam@147
|
20 valgrind ./capnp-test -fcapnp/fuzz-test.c++
|
|
cannam@147
|
21
|
|
cannam@147
|
22 * Manually run the AFL fuzz tests by running `afl-fuzz.sh`. There are three test cases, and ideally each should run for 24 hours or more.
|
|
cannam@147
|
23
|
|
cannam@147
|
24 **Documenting**
|
|
cannam@147
|
25
|
|
cannam@147
|
26 * Write a blog post discussing what is new, placing it in doc/_posts.
|
|
cannam@147
|
27
|
|
cannam@147
|
28 * Run jekyll locally and review the blog post and docs.
|
|
cannam@147
|
29
|
|
cannam@147
|
30 **Releasing**
|
|
cannam@147
|
31
|
|
cannam@147
|
32 * Check out the master branch in a fresh directory. Do NOT use your regular repo, as the release
|
|
cannam@147
|
33 script commits changes and if anything goes wrong you'll probably want to trash the whole thing
|
|
cannam@147
|
34 without pushing. DO NOT git clone the repo from an existing local repo -- check it out directly
|
|
cannam@147
|
35 from github. Otherwise, when it pushes its changes back, they'll only be pushed back to your
|
|
cannam@147
|
36 local repo.
|
|
cannam@147
|
37
|
|
cannam@147
|
38 * Run `./release.sh candidate`. This creates a new release branch, updates the version number to
|
|
cannam@147
|
39 `-rc1`, builds release tarballs, copies them to the current directory, then switches back to the
|
|
cannam@147
|
40 master branch and bumps the version number there. After asking for final confirmation, it will
|
|
cannam@147
|
41 upload the tarball to S3 and push all changes back to github.
|
|
cannam@147
|
42
|
|
cannam@147
|
43 * Install your release candidates on your local machine, as if you were a user.
|
|
cannam@147
|
44
|
|
cannam@147
|
45 * Go to `c++/samples` in the git repo and run `./test.sh`. It will try to build against your
|
|
cannam@147
|
46 installed copy.
|
|
cannam@147
|
47
|
|
cannam@147
|
48 * Post the release candidates somewhere public and then send links to the mailing list for people
|
|
cannam@147
|
49 to test. Wait a bit for bug reports.
|
|
cannam@147
|
50
|
|
cannam@147
|
51 * If there are any problems, fix them in master and start a new release candidate by running
|
|
cannam@147
|
52 `./release.sh candidate <commit>...` from the release branch. This will cherry-pick the specified
|
|
cannam@147
|
53 commits into the release branch and create a new candidate. Repeat until all problems are fixed.
|
|
cannam@147
|
54 Be sure that any such fixes include tests or process changes so that they don't happen again.
|
|
cannam@147
|
55
|
|
cannam@147
|
56 * You should now be ready for an official release. Run `./release.sh final`. This will remove the
|
|
cannam@147
|
57 "-rcN" suffix from the version number, update the version number shown on the downloads page,
|
|
cannam@147
|
58 build the final release package, and -- after final confirmation -- upload the binary, push
|
|
cannam@147
|
59 changes to git, and publish the new documentation.
|
|
cannam@147
|
60
|
|
cannam@147
|
61 * Submit the newly-published blog post to news sites and social media as you see fit.
|
|
cannam@147
|
62
|
|
cannam@147
|
63 * If problems are discovered in the release, fix them in master and run
|
|
cannam@147
|
64 `./release.sh candidate <commit>...` in the release branch to start a new micro release. The
|
|
cannam@147
|
65 script automatically sees that the current branch's version no longer contains `-rc`, so it starts
|
|
cannam@147
|
66 a new branch. Repeat the rest of the process above. If you decide to write a blog post (not
|
|
cannam@147
|
67 always necessary), do it in the master branch and cherry-pick it.
|
