Trac is being migrated to new services! Issues can be found in our new YouTrack instance and WIKI pages can be found on our website.

Version 61 (modified by MarkDoliner, 11 years ago) (diff)

The alternate steps for "make release" seemed a little off to me. Honestly I'm not sure we need to go into too much detail here... people can always look at Makefile.am if they want to know what "make release" does. Meh.

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

  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 (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. Run ./autogen.sh
  4. 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.
  5. Build on Windows
    1. Add the sha1sum for the debug symbols zip file to download_redir.php
    2. If there's a new GTK+ Bundle, upload the zip file to Sourceforge and add the sha1sum to download_redir.php
    3. 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
      
    4. 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
      
  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 http://hg.pidgin.im/www/pidgin/ (this is used by the release notification plugin)
    3. Update the ChangeLog wiki page
  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/mercurial_support/trac-hg-post-commit-hook.py on imperial)
  7. Update "The Road to" on WikiStart to list tickets for the new version
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!