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 at ​http://developer.pidgin.im/l10n/
4. Make sure the newest pidgin.pot exists at ​https://www.transifex.com/projects/p/pidgin/resources/
5. Send an email to translators@… and devel@… announcing the string freeze.

Pre Release

1. Commit pending translation updates from our Trac and ​Transifex (it's possible that only Mark and Richard are able to get translations from Transifex--create an account and talk to them if you want access). Remember to strip location info from them before committing as described in TipsForTranslators. And it's good to test for mismatched c-format specifiers: "msgfmt -cv NN"
2. Check there are no open tickets for this release milestone
3. Make sure the date and version number are correct in ChangeLog
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

Release

1. Tag the repository.

   TAG=v2.6.2 # for example
   mtn tag $REVISION $TAG
   

2. Check out the tagged code

   mtn -d $DATABASE co -r t:$TAG pidgin-$VERSION
   

3. Run ./autogen.sh
4. Run make release
   This will perform the following steps (which can also be done by hand at this point):
   1. Run make distcheck (optional; use make packages instead of make release to skip this in automation. It really is a good idea, though!)
   2. Verify that the revision tagged with this version's tag name (v$VERSION) is the same as the revision in the current workspace, and that there are no changes to the current workspace
   3. Run make dist-gzip and make dist-bzip2
   4. Sign the two tarballs

      gpg -ab pidgin-$VERSION.tar.gz
      gpg -ab pidgin-$VERSION.tar.bz2
      gpg --verify pidgin-$VERSION.tar.gz.asc pidgin-$VERSION.tar.gz
      gpg --verify pidgin-$VERSION.tar.bz2.asc pidgin-$VERSION.tar.bz2
      

5. Build on Windows
6. Upload the two tarballs, the two signatures, and the Windows builds to ​Sourceforge
7. Wait a few hours and let people test.
8. Update the Pidgin website
   1. Change inc/version.inc.php (only for full releases, not for betas)
   2. Update the ChangeLog in pidgin.im web mtn (this is used by the release notification plugin)
   3. Update the ChangeLog
9. 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 [dev]
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/monotone_support/trac-mtn-post-commit-hook.py on imperial)
7. Update "The Road to" on WikiStart to list tickets for the new version