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:
  2. Make sure the newest pidgin.pot exists at Transifex
  3. 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 for the following steps.

Steps

  1. Fetch and commit all translations from Transifex.
  2. cd po
  3. make pidgin.pot
  4. tx pull --force - Pulls all translations from Transifex, even if local timestamp is newer than remote.
  5. XGETTEXT_ARGS=--no-location intltool-update --report - Merges current strings into translations and strips filename and line numbers to keep diffs smaller.
  6. 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.)
  2. Check there are no open tickets for this release milestone
  3. Make sure the date and version number are correct in ChangeLog and ChangeLog.API
  4. 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
  5. Check pidgin.spec.in, make sure that %define beta 7 is commented/uncommented appropriately
  6. Run make distcheck and fix any problems it turns up
  7. Test a tarball to make sure everything works
  8. Verify that win32 builds succeed (including building installers).

Release

  1. Tag the repository. The tag should have a v prefix. Ie: v2.12.0.

  2. Extract the tagged code hg archive -r $TAG ../pidgin-$VERSION.

  3. cd ../pidgin-$VERSION

  4. Run ./autogen.sh

  5. Run make release: This will perform the following steps (which can also be done by hand at this point):

  6. make commit-check - Checks a few files for correctness (UTF-8 encoding, sort order, etc.).

  7. 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.

  8. 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.

  9. make sign-packages - Creates a gpg signature of the two tarballs.

  10. [wiki:BuildingWinPidgin Build on Windows]

  11. If there’s a new GTK Bundle, upload the zip file to Sourceforge 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).

  12. 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

  13. 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

  14. hg push the tag.

  15. Upload the two tarballs, the two signatures, and the Windows builds to Sourceforge

  16. Wait a few hours and let people test.

  17. Build and upload new API docs.

    1. Run make locally?
    2. scp docs/reference/libpurple/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/libpurple/
    3. scp docs/reference/pidgin/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/pidgin/
    4. scp docs/reference/finch/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/finch/

  18. Update the Pidgin website

    1. Change inc/version.inc.php (only for full releases, not for betas)
    2. Update the ChangeLog in keep.imfreedom.org/pidgin/nest/ (this is used by the release notification plugin)

  19. 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 configure.ac & set purple_version_suffix and gnt_version_suffix to devel
  2. Update #pidgin topic
  3. Add new Trac Version for this release
  4. Add new Trac milestone for the next release
  5. “Complete” old milestone
  6. 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)
  7. Update “The Road to” on WikiStart to list tickets for the new version

Looking to reach us via XMPP? Check out the new PidginChat service!