Version 56 (modified by 12 years ago) (diff) | ,
---|
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.
- Are there any branches that need to be merged into trunk (e.g. pidgin.mxit)?
- 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
- Make sure the newest pidgin.pot exists at http://developer.pidgin.im/l10n/
- Make sure the newest pidgin.pot exists at https://www.transifex.com/projects/p/pidgin/resources/
- Send an email to translators@… and devel@… announcing the string freeze.
Pre Release
- 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
" - Check there are no open tickets for this release milestone
- Make sure the date and version number are correct in ChangeLog
- Change version number at the top of configure.ac, set
purple_version_suffix
andgnt_version_suffix
to[betaN]
for betas and[]
for a full release - Check pidgin.spec.in, make sure that "%define beta 7" is commented/uncommented appropriately
- Run '
make distcheck
' and fix any problems it turns up - Test a tarball to make sure everything works
- Verify that win32 builds succeed
Release
- Tag the repository.
TAG=v2.6.2 # for example mtn tag $REVISION $TAG
- Check out the tagged code
mtn -d $DATABASE co -r t:$TAG pidgin-$VERSION
- Run
./autogen.sh
- Run
make release
This will perform the following steps (which can also be done by hand at this point):- Run
make distcheck
(optional; usemake packages
instead ofmake release
to skip this in automation. It really is a good idea, though!) - 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
- Run
make dist-gzip
andmake dist-bzip2
- 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
- Run
- Build on Windows
- Upload the two tarballs, the two signatures, and the Windows builds to Sourceforge
- Wait a few hours and let people test.
- Update the Pidgin website
- Change inc/version.inc.php (only for full releases, not for betas)
- Update the ChangeLog in pidgin.im web mtn (this is used by the release notification plugin)
- Update the ChangeLog
- Send announcement email to announce and packagers mailing lists (sending to announce also sends to support and devel)
Post Release
- Increment version number in configure.ac & set purple_version_suffix and gnt_version_suffix to [dev]
- Update #pidgin topic and on-join message
- Add new Trac Version for this release
- Add new Trac milestone for the next release
- "Complete" old milestone
- 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)
- Update "The Road to" on WikiStart to list tickets for the new version