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