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/pidgin.pot
4. Make sure the newest pidgin.pot exists at ​http://www.transifex.net/projects/p/pidgin/resource/pidgin/
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 try to find crazy people to fix any problems it turns up
7. Make a test tarball and RPM and test to make sure everything works
8. Verify that win32 builds succeed
9. Make sure the Help->About logo is either unversioned or specifies the right version number

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 the SRPM

      rpmbuild -ts --sign --with avahi --with dbus --with meanwhile \
          --with sasl --with silc --with tcl pidgin-$VERSION.tar.bz2
      

5. Upload the two tarballs, the two signatures, and the src.rpm
6. Make RPMs for lots of distributions and upload them
   1. Install the src.rpm

      rpm -Uvh pidgin-$VERSION-0.src.rpm
      

   2. Edit $rpmbuild/SPECS/pidgin.spec and append the distro name to the end of the Release line. For example, ".fc5"
   3. Build

      rpmbuild -bb --sign --with avahi --with dbus --with meanwhile \
          --with sasl --with silc --with tcl $rpmbuild/SPECS/pidgin.spec
      

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. Announce via sourceforge
10. Send announcement email to announce, devel, packagers, and support mailing lists

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. Update Trac Version field to include new version
4. Add a new Trac milestone for the new version
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