jason/nest

Add the start of the release-process page

2017-09-21, Gary Kramlich
4bbd18411ad5
Parents edca726bbd40
Children b98fff9aab31
Add the start of the release-process page
2 files changed, 90 insertions(+), 1 deletions(-)
  • +2 -1
    readme.md
  • +88 -0
    release-process.md
    • --- a/readme.md Mon Sep 18 22:57:30 2017 -0500
    +++ b/readme.md Thu Sep 21 23:44:57 2017 -0500
    @@ -7,4 +7,5 @@
    * [Community](community.md)
    * [Contributing](contributing.md)
    * [Design Guidelines](design-guidelines.md)
    - * [Development FAQ](development-faq.md)
    \ No newline at end of file
    + * [Development FAQ](development-faq.md)
    + * [Release Process](release-process.md)
    --- /dev/null Thu Jan 01 00:00:00 1970 +0000
    +++ b/release-process.md Thu Sep 21 23:44:57 2017 -0500
    @@ -0,0 +1,88 @@
    +# Release Process
    +
    +The release process for Pidgin is kind of tedious but is described in great detail below.
    +
    +## String Freeze
    +A string freeze should be announced about a week before each release, or longer if a large number of strings have changed. This is a guarantee from the developers to the translators that no more strings will be added or changed so that the translators aren't trying to hit a moving target.
    +
    + 1. In a clean workspace, cd into the `po/`` directory and run `intltool-update --maintain`. This will print warnings if there are files that need to be added to either POTFILES.in or POTFILES.skip:
    + 1. Make sure the newest pidgin.pot exists at [Transifex](https://www.transifex.com/projects/p/pidgin/resources/)
    + 1. Send an email to translators@pidgin.im and devel@pidgin.im announcing the string freeze.
    +
    +## Pre-Release
    +
    +### Commit Updated Translations
    +
    +**Background**
    +
    +Transifex is configured to automatically pull `pidgin.pot` from https://developer.pidgin.im/l10n/. When it gets a new `pidgin.pot` it merges the updates to all translations and bumps the "last updated" timestamp. Because of this it's difficult to tell which translations have updates from translators. Because of this we fetch and commit ***all*** translations from Transifex before releasing.
    +
    +**Note**
    +
    +Ask Gary Kramlich or Richard Laager if you need administrative access to [Pidgin's Transifex project](https://www.transifex.com/projects/p/pidgin/resources/) for the following steps.
    +
    +**Steps**
    + 1. Fetch and commit all translations from Transifex.
    + a. `cd po`
    + a. `make pidgin.pot`
    + a. `tx pull --force` - Pulls all translations from Transifex, even if local timestamp is newer than remote.
    + a. `XGETTEXT_ARGS=--no-location intltool-update --report` - Merges current strings into translations and strips filename and line numbers to keep diffs smaller.
    + a. `find -name \*.po -exec msgfmt -cv {} \;` - Check for mismatched c-format specifiers. These can cause crashes so look at the output carefully! If any are found, follow these steps:
    + 1. Edit the translation in Transifex.
    + 1. Remove the string with the mismatched c-format specifiers (leave it blank).
    + 1. `tx pull --force --language=NN` - Pull the updated translation from Transifex.
    +
    +**Other Pre-Release Steps**
    + 1. Make sure list of translators in `pidgin/gtkdialogs.c` matches the Transifex translations teams. (TODO: This is labor intensive and error prone. Should find a way to automate.)
    + 1. Check there are no open tickets for this release milestone
    + 1. Make sure the date and version number are correct in ChangeLog and ChangeLog.API
    + 1. Change version number at the top of configure.ac, set `purple_version_suffix` ***and*** `gnt_version_suffix` to `[betaN]` for betas and `[]` for a full release
    + 1. Check `pidgin.spec.in`, make sure that `%define beta 7` is commented/uncommented appropriately
    + 1. Run `make distcheck` and fix any problems it turns up
    + 1. Test a tarball to make sure everything works
    + 1. Verify that win32 builds succeed (including building installers).
    +
    +## Release
    + 1. Tag the repository. The tag should have a `v` prefix. Ie: `v2.12.0`.
    + 1. Extract the tagged code `hg archive -r $TAG ../pidgin-$VERSION`.
    + 1. `cd ../pidgin-$VERSION`
    + 1. Run `./autogen.sh`
    + 1. Run `make release`
    + This will perform the following steps (which can also be done by hand at this point):
    + a. `make commit-check` - Checks a few files for correctness (UTF-8 encoding, sort order, etc.).
    + a. `make version-check` - Make sure version string does not contain "dev," version is correct in ChangeLogs, and we're building from a clean hg tag.
    + a. `make distcheck` - Standard automake target. Builds and verifies tarballs. If "distcheck" fails and you're sure the failure is innocuous then you can use `make dist`, instead.
    + a. `make sign-packages` - Creates a gpg signature of the two tarballs.
    + 1. [wiki:BuildingWinPidgin Build on Windows]
    + a. If there's a new GTK+ Bundle, upload the zip file to [Sourceforge](https://sourceforge.net/projects/pidgin/files/Pidgin/) and make sure that the `BUNDLE_SHA1SUM` in `pidgin/win32/nsis/generate_gtk_zip.sh` is correct (this should have been checked before `make release`).
    + a. Check the authenticode signature and timestamp for the installers (unfortunately needs to be done on a Windows box with the Platform SDK installed)
    +```
    +signtool.exe verify /pa /tw pidgin-$VERSION-offline.exe
    +signtool.exe verify /pa /tw pidgin-$VERSION.exe
    +```
    + a. Install `pidgin-$VERSION-offline.exe` and check the authenticode signature and timestamp of pidgin.exe
    +```
    +signtool.exe verify /pa /tw %ProgramFiles(x86)%\Pidgin\pidgin.exe
    +```
    + 1. `hg push` the tag.
    + 1. Upload the two tarballs, the two signatures, and the Windows builds to [Sourceforge](https://sourceforge.net/projects/pidgin/files/Pidgin/)
    + 1. Wait a few hours and let people test.
    + 1. Build and upload new API docs.
    + a. Run `make` locally?
    + a. `scp docs/reference/libpurple/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/libpurple/`
    + a. `scp docs/reference/pidgin/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/pidgin/`
    + a. `scp docs/reference/finch/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/finch/`
    + 1. Update the Pidgin website
    + a. Change `inc/version.inc.php` (only for full releases, not for betas)
    + a. Update the ChangeLog in https://bitbucket.org/pidgin/www/ (this is used by the release notification plugin)
    + 1. Send announcement email to announce and packagers mailing lists (sending to announce also sends to support and devel)
    + * Someone must approve the posts in the [support](https://pidgin.im/cgi-bin/mailman/admindb/support) and [devel](https://pidgin.im/cgi-bin/mailman/admindb/devel) admin interface.
    +
    +## Post Release
    + 1. Increment version number in `configure.ac` & set `purple_version_suffix`and `gnt_version_suffix` to `devel`
    + 1. Update `#pidgin` topic
    + 1. Add new Trac Version for this release
    + 1. Add new Trac milestone for the next release
    + 1. "Complete" old milestone
    + 1. Bump the auto-close script to target auto-closed bugs to the new milestone (/srv/trac/developer.pidgin.im/mercurial_support/trac-hg-post-commit-hook.py on nicobar.pidgin.im)
    + 1. Update "The Road to" on WikiStart to list tickets for the new version
    \ No newline at end of file