github.com/blixtra/rkt@v0.8.1-0.20160204105720-ab0d1add1a43/Documentation/devel/release.md (about)

     1  # rkt release guide
     2  
     3  How to perform a release of rkt.
     4  This guide is probably unnecessarily verbose, so improvements welcomed.
     5  Only parts of the procedure are automated; this is somewhat intentional (manual steps for sanity checking) but it can probably be further scripted, please help.
     6  
     7  The following example assumes we're going from version 0.15.0 (`v0.15.0`) to 0.16.0 (`v0.16.0`).
     8  
     9  Let's get started:
    10  
    11  - Start at the relevant milestone on GitHub (e.g. https://github.com/coreos/rkt/milestones/v0.16.0): ensure all referenced issues are closed (or moved elsewhere, if they're not done). Close the milestone.
    12  - Update the [roadmap](https://github.com/coreos/rkt/blob/master/ROADMAP.md) to remove the release you're performing, if necessary
    13  - Branch from the latest master, make sure your git status is clean
    14  - Ensure the build is clean!
    15    - `git clean -ffdx && ./autogen.sh && ./configure --enable-tpm=no --enable-functional-tests && make && make check` should work
    16    - Integration tests on CI should be green
    17  - Update the [release notes](https://github.com/coreos/rkt/blob/master/CHANGELOG.md).
    18    Try to capture most of the salient changes since the last release, but don't go into unnecessary detail (better to link/reference the documentation wherever possible).
    19  
    20  The rkt version is [hardcoded in the repository](https://github.com/coreos/rkt/blob/master/configure.ac#L2), so the first thing to do is bump it:
    21  
    22  - Run `scripts/bump-release v0.16.0`.
    23    This should generate two commits: a bump to the actual release (e.g. v0.16.0), and then a bump to the release+git (e.g. v0.16.0+git).
    24    The actual release version should only exist in a single commit!
    25  - Sanity check what the script did with `git diff HEAD^^` or similar.
    26    As well as changing the actual version, it also attempts to fix a bunch of references in the documentation etc.
    27  - Fix the commit `HEAD^^` so that the version in `stage1/aci/aci-manifest.in` is correct.
    28  - If the script didn't work, yell at the author and/or fix it.
    29    It can almost certainly be improved.
    30  - File a PR and get a review from another [MAINTAINER](https://github.com/coreos/rkt/blob/master/MAINTAINERS).
    31    This is useful to a) sanity check the diff, and b) be very explicit/public that a release is happening
    32  - Ensure the CI on the release PR is green!
    33  
    34  After merging and going back to master branch, we check out the release version and tag it:
    35  
    36  - `git checkout HEAD^` should work; sanity check configure.ac (2nd line) after doing this
    37  - Build rkt, we'll use this in a minute:
    38    - `git clean -ffdx && ./autogen.sh && ./configure --enable-tpm=no && make BUILDDIR=release-build -j 4`
    39      - This will build the `coreos`, `kvm` and `fly` flavors and make `coreos` the default
    40      - Use make's `-j` parameter as you see fit
    41    - Sanity check `release-build/bin/rkt version`
    42    - Sanity check `ldd release-build/bin/rkt`: it can contain linux-vdso.so, libpthread.so, libc.so, ld-linux-x86-64.so but nothing else.
    43    - Sanity check `ldd release-build/tools/init`: in addition to the previous list, it can contain libdl.so, but nothing else.
    44  - Add a signed tag: `git tag -s v0.16.0`.
    45    (We previously used tags for release notes, but now we store them in CHANGELOG.md, so a short tag with the release name is fine).
    46  - Push the tag to GitHub: `git push --tags`
    47  
    48  Now we switch to the GitHub web UI to conduct the release:
    49  
    50  - https://github.com/coreos/rkt/releases/new
    51  - Tag "v0.16.0", release title "v0.16.0"
    52  - For now, check "This is a pre-release"
    53  - Copy-paste the release notes you added earlier in [CHANGELOG.md](https://github.com/coreos/rkt/blob/master/CHANGELOG.md)
    54  - You can also add a little more detail and polish to the release notes here if you wish, as it is more targeted towards users (vs the changelog being more for developers); use your best judgement and see previous releases on GH for examples.
    55  - Attach the release.
    56    This is a simple tarball:
    57  
    58  ```
    59  	export NAME="rkt-v0.16.0"
    60  	mkdir $NAME
    61  	cp release-build/bin/rkt release-build/bin/stage1-{coreos,kvm,fly}.aci $NAME/
    62  	cp -r dist/* $NAME/
    63  	tar czvf $NAME.tar.gz $NAME/
    64  ```
    65  
    66  - Attach the release signature; your personal GPG is okay for now:
    67  
    68  ```
    69  	gpg --detach-sign $NAME.tar.gz
    70  ```
    71  
    72  - Publish the release!
    73  
    74  Now it's announcement time: send an email to rkt-dev@googlegroups.com describing the release.
    75  Generally this is higher level overview outlining some of the major features, not a copy-paste of the release notes.
    76  Use your discretion and see [previous release emails](https://groups.google.com/forum/#!forum/rkt-dev) for examples.
    77  Make sure to include a list of authors that contributed since the previous release - something like the following might be handy:
    78  
    79  ```
    80  	git log ...v0.16.0 --pretty=format:"%an" | sort | uniq | tr '\n' ',' | sed -e 's#,#, #g' -e 's#, $#\n#'
    81  ```
    82  
    83  - Prepare CHANGELOG.md for the next release: add a "vUNRELEASED" section. The CHANGELOG should be updated alongside the code as pull requests are merged into master, so that the releaser does not need to start from scratch.