Moves orphan content to draft folder and adds frontmatter
--- a/content/design-guidelines.md Mon Jan 14 00:04:40 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,42 +0,0 @@
-These guidelines are informal descriptions of the sort of thinking that goes into the design of Pidgin, libpurple, and family. These are not hard-and-fast rules, but they are conscious decisions made by the Pidgin developers which will be violated only after careful consideration. (Or by mistake, and corrected shortly thereafter!)-While Pidgin is a multiprotocol IM client, the goal is to hide protocols from the user as much as possible. Obviously users have to know about individual protocols when they create or modify accounts, but in day-to-day communication and usage, the intent is that users don't have to think about protocols at all.-The workflow in Pidgin is intended to be "I would like to chat with Sean about wibbles", not "I would like to create an XMPP conversation with seanegan@pidgin.im".-The focus is on the goal, not the process. In reaching toward this focus, we have chosen to paper over the differences between the various protocols and features as much as possible (without crippling or needlessly complicating things). This has lead to decisions such as the removal of protocol icons from the buddy list and the implementation of contact-aware chats and logs.-> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.-> --Antoine de Saint-Exupery-In general we try to keep the code and the user interface simple. Especially when it comes to preferences in the UI. Pidgin should be as streamlined as possible. It is an IM client, so messaging someone should be easy. See [this essay](http://www106.pair.com/rhp/free-software-ui.html) by Havoc Pennington for an explanation of some ideas that we try to follow.-It's important for the code to be simple because this is an open source project and developers come and go. You never know who's going to be looking at your code next. If you write a function that's hard to follow then the next person that comes along will end up rewriting it, and that's counterproductive.-In plain language, this means that the protocol-specific code goes in the protocol plugin (*prpl*), and that libpurple exists, and is cleanly separated from the user interface. There are practical implications to this. While all of our code depends on glib, only the Pidgin specific parts depend on GTK+.-To implement, for example, file transfer; there are 3 steps. First, the protocol(s) have to support it. By themselves, however, the protocols can do nothing. So the "core," libpurple, has to support it also (the second step).-We do not want massive amounts of very similar code in libpurple, so the implementation of file transfer at the libpurple level has to abstract away from how individual protocols handle it, so as to be able to use the same calls from all file transfer supporting protocols.-Last, but not least, before the user can actually send or receive a file, the UI (Pidgin, Finch, or Adium) must support it. These interfaces know nothing about the protocol, and have only limited contact with the core. This helps to enforce the desire for uniformity explained above. It also makes it easier for the only sort of duplication we encourage: many interfaces. The core implementation cannot assume too much about what the UI will do, because the GTK+ UI (Pidgin) might need to handle a file transfer somewhat differently than the ncurses based UI (Finch).-Patches that voilate this layering will be rejected. In practice, this means that there is more work involved to introduce a new class of functionality, say file transfer, white-boarding, voice, or video. On the other hand, it means less work to implement any given class of functionality for a new protocol or for a new UI.-Our source code is very much a 'live' document. It should reflect what is currently needed, not what used to be needed or what might be needed in the future. Old code should be removed if it isn't being used (of course, you can only remove public functions and structures when the major version number increases)--it'll always be in the source code repository if anyone needs it. The code should contain documentation about what it does and why.-Pidgin and libpurple are single threaded. That means that the network code runs in the same process as the user interface. Network code must be non-blocking, otherwise the UI will be unresponsive. Code should be event-driven. Long running tasks should be asynchronous. File descriptors that need to be watched for changes should be added to the event loop.\ No newline at end of file
--- a/content/development-faq.md Mon Jan 14 00:04:40 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,99 +0,0 @@
-The following is a list of Frequently Asked Questions (FAQs), with answers, and notes related to development using LibPurple.-### I created an account, but it's not being saved!-You need to use `purple_accounts_add()` to add the account to the list of available accounts. This list of accounts is saved. Note that many of the functions require an account to be on that list. So you should always call `purple_accounts_add()` after creating an account.-### How do I get online with an account?-There are two ways you can do this:- * If you have other accounts online, and you want the new account to have the same status as those, then call `purple_savedstatus_get_current()` to get the current status, and use `purple_savedstatus_activate_for_account()` for the account.- * Otherwise, you can simply do `purple_account_set_status()` to set the status of the account.-An account needs to be enabled before it can be connected. So after doing either of the above, you need to enable the account by calling `purple_account_set_enabled()`.-### How can I create a conversation with someone?-Use `purple_conversation_new()`. Use `PURPLE_CONV_TYPE_IM` if the conversation is an IM (one-to-one person conversation), and use `PURPLE_CONV_TYPE_CHAT` if it's a multi-user conversation. One important thing to note here is that the name property of the `PurpleConversation` struct is the name of the buddy you are creating a conversation with (the documentation states that this is the name of the conversation itself, but it is in fact also the name of the receiving buddy). So a call to `purple_conversation_new()` takes the name of the buddy as its third argument.-### How can I send a message in a conversation?-Use either `purple_conv_im_send()` or `purple_conv_chat_send()`. Note that the first parameter to either of these functions are ***not*** the conversation itself. Rather, it's the IM data or chat data of the conversation which you can get from `PURPLE_CONV_IM`/`PURPLE_CONV_CHAT`.-### Is there a way that I can print something in the conversation window, but not send the message?-Yes. Use `purple_conv_im_write()` or `purple_conv_chat_write()`.-### What do I do with `DATADIR`, `LOCALEDIR`, and `LIBDIR`?-`DATADIR`, `LOCALEDIR`, and `LIBDIR` are defined as functions in the Windows build. Therefore, doing something like this will break the Windows build:- printf("File in DATADIR is: %s\n", DATADIR G_DIR_SEPARATOR_S "pic.png")- printf("File in DATADIR is: %s%s%s\n", DATADIR, G_DIR_SEPARATOR_S, "pic.png");-### Why are files opened with mode `b`?-Without this, on Windows systems the opened files will use Windows default translation (<CR><LF> for newline, for example). This will cause errors due to newline format and the "bytes read" counts, which will be wrong when comparing the return value of `read()` to `stat()`.-### Why are `G_DIR_SEPARATOR_S` and `G_DIR_SEPARATOR` used everywhere?-This is a matter of maintaining cross-platform compatibility. Windows uses a backslash ("\") for directory separators in paths, while UNIX-like systems use the forward slash ("/"). Other OSes may choose to use other separators--for example, prior to Mac OS X, it was common for the directory separator on Macs to be a colon (":").-It is impractical to use preprocessor directives throughout the code to determine the path style to use, especially if a new OS were to appear and use a different directory separator. GLib, which we already use, provides the convenient separator macro, so we use this to reduce our code complexity and maintain cross-platform portability.-### What should I do to get the contents of an environment variable?-### Should I use `snprintf()` or `vsnprintf()`?-No. Use the GLib wrapper functions instead. They are `g_snprintf()` and `g_vsnprintf()`.-### How do I get the settings directory?-Use `purple_home_dir()`. You should *not* use `g_get_home_dir()` or `getenv("HOME")`.-### What is the versioning scheme?-**This is already defined elsewhere, we should probably just have a page for it... --grim**-There are three fields in the version: `major.minor.micro`.- * If the `major` is changing, you can break plugins. That means both forward- and backward- compatibility. API can be added or removed or whatever you like.- * If only the `minor` is changing, you can break forward compatibility only. You may add API, but you can't remove it. You can mark API as deprecated instead.- * If only the `micro` is changing, you can't break the API at all.-### Why is win32dep.h causing problems for me?-You need to make sure it is the last header you include if you need to include it. Not doing so is asking for problems.-## Plugins and Protocols-### How should I handle global variables?-Use `G_MODULE_IMPORT` for any global variable located outside your dynamic library. Not doing this will cause "Memory Access Violation" errors on Windows systems.-### What should I do for "exported" functions?-If your plugin has functions that are to be accessed from outside the scope of its file (.dll or .so), `G_MODULE_EXPORT` those functions.--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/drafts/_index.md Mon Jan 14 18:49:58 2019 +0000
@@ -0,0 +1,6 @@
+**THIS PAGE SHOULD NOT BE IN PRODUCTION** \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/drafts/design-guidelines.md Mon Jan 14 18:49:58 2019 +0000
@@ -0,0 +1,45 @@
+title: "Design Guidelines" +These guidelines are informal descriptions of the sort of thinking that goes into the design of Pidgin, libpurple, and family. These are not hard-and-fast rules, but they are conscious decisions made by the Pidgin developers which will be violated only after careful consideration. (Or by mistake, and corrected shortly thereafter!) +While Pidgin is a multiprotocol IM client, the goal is to hide protocols from the user as much as possible. Obviously users have to know about individual protocols when they create or modify accounts, but in day-to-day communication and usage, the intent is that users don't have to think about protocols at all. +The workflow in Pidgin is intended to be "I would like to chat with Sean about wibbles", not "I would like to create an XMPP conversation with seanegan@pidgin.im". +The focus is on the goal, not the process. In reaching toward this focus, we have chosen to paper over the differences between the various protocols and features as much as possible (without crippling or needlessly complicating things). This has lead to decisions such as the removal of protocol icons from the buddy list and the implementation of contact-aware chats and logs. +> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. +> --Antoine de Saint-Exupery +In general we try to keep the code and the user interface simple. Especially when it comes to preferences in the UI. Pidgin should be as streamlined as possible. It is an IM client, so messaging someone should be easy. See [this essay](http://www106.pair.com/rhp/free-software-ui.html) by Havoc Pennington for an explanation of some ideas that we try to follow. +It's important for the code to be simple because this is an open source project and developers come and go. You never know who's going to be looking at your code next. If you write a function that's hard to follow then the next person that comes along will end up rewriting it, and that's counterproductive. +In plain language, this means that the protocol-specific code goes in the protocol plugin (*prpl*), and that libpurple exists, and is cleanly separated from the user interface. There are practical implications to this. While all of our code depends on glib, only the Pidgin specific parts depend on GTK+. +To implement, for example, file transfer; there are 3 steps. First, the protocol(s) have to support it. By themselves, however, the protocols can do nothing. So the "core," libpurple, has to support it also (the second step). +We do not want massive amounts of very similar code in libpurple, so the implementation of file transfer at the libpurple level has to abstract away from how individual protocols handle it, so as to be able to use the same calls from all file transfer supporting protocols. +Last, but not least, before the user can actually send or receive a file, the UI (Pidgin, Finch, or Adium) must support it. These interfaces know nothing about the protocol, and have only limited contact with the core. This helps to enforce the desire for uniformity explained above. It also makes it easier for the only sort of duplication we encourage: many interfaces. The core implementation cannot assume too much about what the UI will do, because the GTK+ UI (Pidgin) might need to handle a file transfer somewhat differently than the ncurses based UI (Finch). +Patches that voilate this layering will be rejected. In practice, this means that there is more work involved to introduce a new class of functionality, say file transfer, white-boarding, voice, or video. On the other hand, it means less work to implement any given class of functionality for a new protocol or for a new UI. +Our source code is very much a 'live' document. It should reflect what is currently needed, not what used to be needed or what might be needed in the future. Old code should be removed if it isn't being used (of course, you can only remove public functions and structures when the major version number increases)--it'll always be in the source code repository if anyone needs it. The code should contain documentation about what it does and why. +Pidgin and libpurple are single threaded. That means that the network code runs in the same process as the user interface. Network code must be non-blocking, otherwise the UI will be unresponsive. Code should be event-driven. Long running tasks should be asynchronous. File descriptors that need to be watched for changes should be added to the event loop. \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/drafts/development-faq.md Mon Jan 14 18:49:58 2019 +0000
@@ -0,0 +1,102 @@
+title: "Development FAQ" +The following is a list of Frequently Asked Questions (FAQs), with answers, and notes related to development using LibPurple. +### I created an account, but it's not being saved! +You need to use `purple_accounts_add()` to add the account to the list of available accounts. This list of accounts is saved. Note that many of the functions require an account to be on that list. So you should always call `purple_accounts_add()` after creating an account. +### How do I get online with an account? +There are two ways you can do this: + * If you have other accounts online, and you want the new account to have the same status as those, then call `purple_savedstatus_get_current()` to get the current status, and use `purple_savedstatus_activate_for_account()` for the account. + * Otherwise, you can simply do `purple_account_set_status()` to set the status of the account. +An account needs to be enabled before it can be connected. So after doing either of the above, you need to enable the account by calling `purple_account_set_enabled()`. +### How can I create a conversation with someone? +Use `purple_conversation_new()`. Use `PURPLE_CONV_TYPE_IM` if the conversation is an IM (one-to-one person conversation), and use `PURPLE_CONV_TYPE_CHAT` if it's a multi-user conversation. One important thing to note here is that the name property of the `PurpleConversation` struct is the name of the buddy you are creating a conversation with (the documentation states that this is the name of the conversation itself, but it is in fact also the name of the receiving buddy). So a call to `purple_conversation_new()` takes the name of the buddy as its third argument. +### How can I send a message in a conversation? +Use either `purple_conv_im_send()` or `purple_conv_chat_send()`. Note that the first parameter to either of these functions are ***not*** the conversation itself. Rather, it's the IM data or chat data of the conversation which you can get from `PURPLE_CONV_IM`/`PURPLE_CONV_CHAT`. +### Is there a way that I can print something in the conversation window, but not send the message? +Yes. Use `purple_conv_im_write()` or `purple_conv_chat_write()`. +### What do I do with `DATADIR`, `LOCALEDIR`, and `LIBDIR`? +`DATADIR`, `LOCALEDIR`, and `LIBDIR` are defined as functions in the Windows build. Therefore, doing something like this will break the Windows build: + printf("File in DATADIR is: %s\n", DATADIR G_DIR_SEPARATOR_S "pic.png") + printf("File in DATADIR is: %s%s%s\n", DATADIR, G_DIR_SEPARATOR_S, "pic.png"); +### Why are files opened with mode `b`? +Without this, on Windows systems the opened files will use Windows default translation (<CR><LF> for newline, for example). This will cause errors due to newline format and the "bytes read" counts, which will be wrong when comparing the return value of `read()` to `stat()`. +### Why are `G_DIR_SEPARATOR_S` and `G_DIR_SEPARATOR` used everywhere? +This is a matter of maintaining cross-platform compatibility. Windows uses a backslash ("\") for directory separators in paths, while UNIX-like systems use the forward slash ("/"). Other OSes may choose to use other separators--for example, prior to Mac OS X, it was common for the directory separator on Macs to be a colon (":"). +It is impractical to use preprocessor directives throughout the code to determine the path style to use, especially if a new OS were to appear and use a different directory separator. GLib, which we already use, provides the convenient separator macro, so we use this to reduce our code complexity and maintain cross-platform portability. +### What should I do to get the contents of an environment variable? +### Should I use `snprintf()` or `vsnprintf()`? +No. Use the GLib wrapper functions instead. They are `g_snprintf()` and `g_vsnprintf()`. +### How do I get the settings directory? +Use `purple_home_dir()`. You should *not* use `g_get_home_dir()` or `getenv("HOME")`. +### What is the versioning scheme? +**This is already defined elsewhere, we should probably just have a page for it... --grim** +There are three fields in the version: `major.minor.micro`. + * If the `major` is changing, you can break plugins. That means both forward- and backward- compatibility. API can be added or removed or whatever you like. + * If only the `minor` is changing, you can break forward compatibility only. You may add API, but you can't remove it. You can mark API as deprecated instead. + * If only the `micro` is changing, you can't break the API at all. +### Why is win32dep.h causing problems for me? +You need to make sure it is the last header you include if you need to include it. Not doing so is asking for problems. +## Plugins and Protocols +### How should I handle global variables? +Use `G_MODULE_IMPORT` for any global variable located outside your dynamic library. Not doing this will cause "Memory Access Violation" errors on Windows systems. +### What should I do for "exported" functions? +If your plugin has functions that are to be accessed from outside the scope of its file (.dll or .so), `G_MODULE_EXPORT` those functions. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/drafts/gsoc-ideas.md Mon Jan 14 18:49:58 2019 +0000
@@ -0,0 +1,28 @@
+## Add Voice and Video to the SIP Plugin --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/drafts/release-process.md Mon Jan 14 18:49:58 2019 +0000
@@ -0,0 +1,91 @@
+title: "Release Process" +The release process for Pidgin is kind of tedious but is described in great detail below. +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. +### Commit Updated Translations +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. +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. + 1. Fetch and commit all translations from Transifex. + a. `tx pull --force` - Pulls all translations from Transifex, even if local timestamp is newer than remote. + a. `XGETTEXT_ARGS=--no-location intltool-update --report` - Merges current strings into translations and strips filename and line numbers to keep diffs smaller. + a. `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). + 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` + This will perform the following steps (which can also be done by hand at this point): + a. `make commit-check` - Checks a few files for correctness (UTF-8 encoding, sort order, etc.). + a. `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. + a. `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. + a. `make sign-packages` - Creates a gpg signature of the two tarballs. + 1. [wiki:BuildingWinPidgin Build on Windows] + a. 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`). + a. 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 + a. 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. 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. + a. `scp docs/reference/libpurple/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/libpurple/` + a. `scp docs/reference/pidgin/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/pidgin/` + a. `scp docs/reference/finch/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/finch/` + 1. Update the Pidgin website + a. Change `inc/version.inc.php` (only for full releases, not for betas) + a. Update the ChangeLog in https://bitbucket.org/pidgin/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. + 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 \ No newline at end of file
--- a/content/gsoc-ideas.md Mon Jan 14 00:04:40 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,25 +0,0 @@
-## Add Voice and Video to the SIP Plugin--- a/content/release-process.md Mon Jan 14 00:04:40 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,88 +0,0 @@
-The release process for Pidgin is kind of tedious but is described in great detail below.-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.-### Commit Updated Translations-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.-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.- 1. Fetch and commit all translations from Transifex.- a. `tx pull --force` - Pulls all translations from Transifex, even if local timestamp is newer than remote.- a. `XGETTEXT_ARGS=--no-location intltool-update --report` - Merges current strings into translations and strips filename and line numbers to keep diffs smaller.- a. `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).- 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`- This will perform the following steps (which can also be done by hand at this point):- a. `make commit-check` - Checks a few files for correctness (UTF-8 encoding, sort order, etc.).- a. `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.- a. `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.- a. `make sign-packages` - Creates a gpg signature of the two tarballs.- 1. [wiki:BuildingWinPidgin Build on Windows]- a. 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`).- a. 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- a. 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. 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.- a. `scp docs/reference/libpurple/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/libpurple/`- a. `scp docs/reference/pidgin/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/pidgin/`- a. `scp docs/reference/finch/html nicobar.pidgin.im:/srv/www/developer.pidgin.im/doxygen/x.y.z/finch/`- 1. Update the Pidgin website- a. Change `inc/version.inc.php` (only for full releases, not for betas)- a. Update the ChangeLog in https://bitbucket.org/pidgin/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.- 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\ No newline at end of file
