hugo/content/development/release-process.md

Thu, 02 Jan 2025 16:35:59 -0600

author
Gary Kramlich <grim@reaperworld.com>
date
Thu, 02 Jan 2025 16:35:59 -0600
changeset 545
cf811d26020d
parent 454
a6832f539981
permissions
-rw-r--r--

Add a flathub verification token

Testing Done:
Ran with `npm run hugo:server` and verified the file was served properly.

Reviewed at https://reviews.imfreedom.org/r/3718/

---
title: Release Process
date: 2019-01-14T18:49:58.000Z
replaces:
  - developer.pidgin.im/wiki/ReleaseProcess
lastmod: 2019-08-23T10:54:49.000Z
---

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:
 1. Make sure the newest pidgin.pot exists at
    [Transifex](https://www.transifex.com/projects/p/pidgin/resources/)
 1. 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](https://www.transifex.com/projects/p/pidgin/resources/) for the
following steps.

**Steps**

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

## Release

 1. Tag the repository.  The tag should have a `v` prefix.  Ie: `v2.12.0`.
 1. Extract the tagged code `hg archive -r $TAG ../pidgin-$VERSION`.
 1. `cd ../pidgin-$VERSION`
 1. Run `./autogen.sh`
 1. 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.).
   1. `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.
   1. `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.
   1. `make sign-packages` - Creates a gpg signature of the two tarballs.
 1. [wiki:BuildingWinPidgin Build on Windows]
   1. If there's a new GTK Bundle, upload the zip file to
      [Sourceforge](https://sourceforge.net/projects/pidgin/files/Pidgin/) 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`).
   1. 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

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

 1. `hg push` the tag.
 1. Upload the two tarballs, the two signatures, and the Windows builds to
    [Sourceforge](https://sourceforge.net/projects/pidgin/files/Pidgin/)
 1. Wait a few hours and let people test.
 1. 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/`
 1. Update the Pidgin website
    1. Change `inc/version.inc.php` (only for full releases, not for betas)
    2. Update the ChangeLog in {{< repo link="1" name="www" >}} (this is used
       by the release notification plugin)
 1. 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](https://pidgin.im/cgi-bin/mailman/admindb/support) and
    [devel](https://pidgin.im/cgi-bin/mailman/admindb/devel) admin interface.

## Post Release

 1. Increment version number in `configure.ac` & set `purple_version_suffix` and
    `gnt_version_suffix` to `devel`
 1. Update `#pidgin` topic
 1. Add new Trac Version for this release
 1. Add new Trac milestone for the next release
 1. "Complete" old milestone
 1. 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)
 1. Update "The Road to" on WikiStart to list tickets for the new version

mercurial