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

Use ``` markdown syntax

Azat Khuzhin 2016-08-07 23:21:41 +03:00
parent 50ae147bff
commit d2edcc7768
1 changed files with 21 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
ReleaseChecklist.md

@ -11,39 +11,44 @@ I wrote up this document as a checklist of stuff to do before putting out a Libe
* 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 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`
* Try building it with MSVC.
* Run "make dist" and make sure it generates a good distribution. You can make sure that it does by running "make distcheck".
* 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
* 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/nmake/event2/event-config.h. (These are not automatically changed by configure.in, since we don't use autoconf with nmake.)
* Increment the libtool VERSION_INFO in Makefile.am. See Makefile.am for full instructions on what to do in other cases.
* Increment the versions in CMakeLists.txt.
* Run "make distcheck" again to make sure nothing above messed us up. Do this one on the system with the most up-to-date autotools you have.
* 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/nmake/event2/event-config.h`. (These are not automatically changed by configure.in, since we don't use `autoconf` with `nmake`.)
* Increment the `libtool` VERSION_INFO in `Makefile.am`. See `Makefile.am` for full instructions on what to do in other cases.
* Increment the versions in `CMakeLists.txt`.
* Run `make distcheck` again to make sure nothing above messed us up. Do this one on the system with the most up-to-date autotools you have.
* 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}"
* 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}."
* 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.
* 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.