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. Are there any branches that need to be merged into trunk (e.g. pidgin.mxit)?
2. In a clean workspace, cd into the po/ directory and run this command. It will print warnings if there are files that need to be added to either POTFILES.in or POTFILES.skip:

   intltool-update --maintain
   

3. Make sure the newest pidgin.pot exists on the l10n page
4. Make sure the newest pidgin.pot exists at ​Transifex
5. Send an email to translators@… and devel@… 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. However, some translators have commit access to our repository and commit their translations directly. We need to upload these translations to Transifex before fetching everything.

Note
Ask Mark Doliner or Richard Laager if you need administrative access to ​Pidgin's Transifex project for the following steps.

Steps

1. Upload pending translation updates from our Trac to Transifex.
2. Find translations that have been committed directly since the last release and upload these to Transifex.

   hg log -b BRANCH_NAME po/
   

3. Fetch and commit all translations from Transifex.
   1. cd po
   2. make pidgin.pot
   3. tx pull --force - Pulls all translations from Transifex, even if local timestamp is newer than remote.
   4. XGETTEXT_ARGS=--no-location intltool-update --report - Merges current strings into translations and strips filename and line numbers to keep diffs smaller.

TODO: Need to check for mismatched c-format specifiers or does Transifex do this for us? msgfmt -cv NN or find -name \*.po -exec msgfmt -cv {} \;

Other Pre-Release Steps

1. Check there are no open tickets for this release milestone
2. Make sure the date and version number are correct in ChangeLog
3. 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
4. Check pidgin.spec.in, make sure that "%define beta 7" is commented/uncommented appropriately
5. Run 'make distcheck' and fix any problems it turns up
6. Test a tarball to make sure everything works
7. Verify that win32 builds succeed (including building installers).

Release

1. Tag the repository.

   VERSION=2.6.2 # for example
   TAG=v$VERSION
   hg tag -r $REVISION $TAG
   

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):
   1. make commit-check - Checks a few files for correctness (UTF-8 encoding, sort order, etc.).
   2. 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.
   3. 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.
   4. make sign-packages - Creates a gpg signature of the two tarballs.
6. 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/generate_gtk_zip.sh is correct (this should have been checked before make release).
   2. 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
      

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

7. Upload the two tarballs, the two signatures, and the Windows builds to ​Sourceforge
8. Wait a few hours and let people test.
9. Update the Pidgin website
   1. Change inc/version.inc.php (only for full releases, not for betas)
   2. Update the ChangeLog in ​https://hg.pidgin.im/www/pidgin/ (this is used by the release notification plugin)
   3. Update the ChangeLog wiki page
10. Send announcement email to announce and packagers mailing lists (sending to announce also sends to support and devel)

Post Release

1. Increment version number in configure.ac & set purple_version_suffix and gnt_version_suffix to [devel]
2. Update #pidgin topic and on-join message
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