Add an alias for /development/wiki/GetABacktrace to the debugging page

Testing Done:
Ran `npm hugo:server` and verified that `/development/wiki/GetABacktrace` redirected to `/development/debugging'

Reviewed at
title: Release Process
date: 2019-01-14T18:49:58.000Z
lastmod: 2019-08-23T10:54:49.000Z
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 or POTFILES.skip:
1. Make sure the newest pidgin.pot exists at
1. Send an email to and announcing the
string freeze.
## Pre-Release
### Commit Updated Translations
Transifex is configured to automatically pull `pidgin.pot` from 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
Ask Gary Kramlich or Richard Laager if you need administrative access to
[Pidgin's Transifex
project]( for the
following steps.
1. Fetch and commit all translations from Transifex.
1. `cd po`
1. `make pidgin.pot`
1. `tx pull --force` - Pulls all translations from Transifex, even if local
timestamp is newer than remote.
1. `XGETTEXT_ARGS=--no-location intltool-update --report` - Merges current
strings into translations and strips filename and line numbers to keep
diffs smaller.
1. `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
1. `tx pull --force --language=NN` - Pull the updated translation from
**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
1. Change version number at the top of, set
`purple_version_suffix` ***and*** `gnt_version_suffix` to `[betaN]` for
betas and `[]` for a full release
1. Check ``, 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 `./`
1. Run `make release`: This will perform the following steps (which can also be
done by hand at this point):
1. `make commit-check` - Checks a few files for correctness (UTF-8 encoding,
sort order, etc.).
1. `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.
1. `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.
1. `make sign-packages` - Creates a gpg signature of the two tarballs.
1. [wiki:BuildingWinPidgin Build on Windows]
1. If there's a new GTK Bundle, upload the zip file to
[Sourceforge]( and
make sure that the `BUNDLE_SHA1SUM` in
`pidgin/win32/nsis/` is correct (this should have been
checked before `make release`).
1. Check the authenticode signature and timestamp for the installers
(unfortunately needs to be done on a Windows box with the Platform SDK
signtool.exe verify /pa /tw pidgin-$VERSION-offline.exe
signtool.exe verify /pa /tw pidgin-$VERSION.exe
1. 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
1. Wait a few hours and let people test.
1. Build and upload new API docs.
1. Run `make` locally?
2. `scp docs/reference/libpurple/html`
3. `scp docs/reference/pidgin/html`
4. `scp docs/reference/finch/html`
1. Update the Pidgin website
1. Change `inc/` (only for full releases, not for betas)
2. Update the ChangeLog in {{< repo link="1" name="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]( and
[devel]( admin interface.
## Post Release
1. Increment version number in `` & 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
1. Update "The Road to" on WikiStart to list tickets for the new version