GitHub/libevent
1
0
Fork 0
mirror of https://github.com/libevent/libevent.git synced 2025-01-31 09:12:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Add a ReleaseChecklist page.

nmathewson 2012-02-10 20:00:38 -08:00
parent 68957d426f
commit cb5c8628a0
1 changed files with 49 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
ReleaseChecklist.md Normal file

@ -0,0 +1,49 @@
# The Libevent Release Checklist
I wrote up this document as a checklist of stuff to do before putting out a Libevent release.
## Part 1: Before the release
TEST!
* Run the unit tests on a few platforms. The ones I currently test are
* Linux (fedora, latest)
* OpenBSD
* FreeBSD
* Windows XP
* OSX 10.5
* OpenSolaris
* Run the various --disable-foo options. They are: --disable-thread-support --disable-malloc-replacement --disable-openssl--disable-debug-mode.
* Try building with -DUSE_DEBUG
* Try building it on windows with -DUNICODE -D_UNICODE
* Run "make dist" and make sure it generates a good distribution. You can make sure that it does by running "make distcheck".
* Make sure all APIs are documented in lebook and in the doxygen comments. This is especially important for alpha, beta, and rc releases, where new APIs are born.
## Part 2: to put out the release
* Set some variables. In the instructions below, I'll assume that you have set: LAST_TAG=release-2.0.17-stable NEW_TAG=release-2.0.18-stable
* Generate the changelog. For generating the contents of the changelog, you can get something pretty close to what we've done in the past by saying:
git log --no-merges --reverse --pretty='format: o %s (%h %an)' ${LAST_TAG}..HEAD | perl -pe 's/ (Nick Mathewson)\)$/\)/'
* Generate the credits. I like to use " git log ${LAST_TAG}..HEAD --pretty='format:%an' > names " for everybody whose name is on a commit, then " git log ${LAST_TAG}..HEAD | perl -ne 'if (/([A-Z]\w* [A-Z]\w*)/) { print "$1\n"; }' >> names " to get all the namelike sequences in the log. Then I use a sort -k2 | uniq pipeline to sort and uniqueify them. These names get stuck in the list in the README, and in the announcement. {NOTE: The perl snippet above is }
* Increment the version number and version string in configure.in. The next version should be 2.0.18-stable; the numeric version should be 0x02001200 (That is, 02 00 12 00 : the first three bytes are the version number, and the final 00 byte means that this is the actual release of 2.0.18, not some development version between 2.0.18 and 2.0.19.)
* Increment the version number and string in WIN32-Code/event2/event-config.h. (These are not automatically changed by configure.in, since we don't use autoconf with msvc.)
* Increment the libtool VERSION_INFO in Makefile.am See Makefile.am for full instructions on what to do in other cases.
* Run "make distcheck" again to make sure nothing above messed us up.
* Upload the resulting tarball somewhere volatile; tell people to try it out.
## Part 3: The point of no return
Once the tarball is tested, it's time to put out the release.
* Tag the release. I do this with
git tag -u 165733ea ${NEW_TAG}
* Push the tag to the origin. This is done with "git push origin tag ${NEW_TAG}"
* Upload the tarball and signature to to sourceforge and github.
* Add a link on the website and on the old releases page.
* Send an announcement to libevent-users
* Increment the version in the IRC channel topic by telling chanserv "set #libevent topic Welcome to #libevent! The latest release is ${NEW_TAG}."
## Part 4: Right after the distribution is done
* Increment the versions in configure.in and WIN32-Code/event2/event-config.h to ${NEW_TAG}-dev, and increment the version numbers there to 0x02001201. The "-dev" and "01" mean that we are a development version, not the released version.
* Add a new empty section for the next version to the changelog.