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