This is a check-list of things to do to make a release of your plugin through WordPress.org. First you must have your plugin registered on WordPress.org.
We assume here, that your code is checked into the WordPress.org’s Subversion (SVN) repository and you are working on the trunk.
1. Give your version a number.
Edit your main plugin file’s informational comment header, (file named like “my-awesome-plugin.php”). The header looks like:
/* Plugin Name: My Awesome Pluin Plugin URI: http://wordpress.org/extend/plugins/my-awesome-plugin/ Version: 0.1 Author: Author name Description: A description here Text Domain: my-awesome-plugin License: GPL3 */
Change the “Version: 0.1” to your new Version. Version numbers should be consistent with what the PHP version_compare function recognizes.
Commit this to SVN.
You can do this well in advance of a release. In fact, you probably should update this after you make a release with the next release number that is in development.
2. Update your readme.txt Changelog
Update your readme.txt file with information about your new version in the “Changelog” section. Assuming your new version is “1.4” you would put a
== Changelog == = 1.4 = * Cool new feature X added * Cool new feature Y added
Do NOT update Stable tag….yet.
Paste the contents in the readme.txt validator to make sure it’s OK.
Commit to SVN
Generally, you should update this file each time you make a noteworthy change to code as you develop it. Don’t wait until you are about to release.
3. Generate an updated .pot file.
This is the reference file that others can use to do translations. Simply go to your plugin’s page on WordPress.org, and go to the Admin panel. The URL is something like “http://wordpress.org/extend/plugins/my-awesome-plugin/admin/”. The click the Generate POT button to create a .pot file from the trunk code.
Save the file under your plugin’s languages/ directory. Commit to SVN.
4. Create an SVN Tag
You want to be sure to tag the latest code on the HEAD of the trunk with a new tag under “tags”. The tag should be a number that is exactly the same as the “Version” number you set in your main plugin file header.
Here is an example Tortoise SVN dialog:
4. Change your Stable Tag in readme.txt
This action actually releases the version to users. The “Stable tag” value signals WordPress.org which version of your software is the released version. Any user installing or upgrading your plugin on their WordPress site will get this version. Once you change the “Stable tag” value those who have your plugin installed will automatically see upgrade notices on their Plugins administrative page. The value of your “Stable tag” should be the SVN tag you created. For example, if you made SVN tag “1.4”, you release that version by setting “Stable tag: 1.4” and committing on the trunk.
Point of confusion: Your “Stable tag” is defined in then trunk version of your readme.txt file, NOT the tagged version. So even though your new release is version 1.4 (for example) and you have a “1.4” SVN tag, you will actually be updating the readme.txt on the trunk. The value of “Stable tag” on the 1.4 tagged version is not used.
Edit the trunk version of your readme.txt file. Change the Stable tag value to match your SVN tag.
Stable tag: 1.4
SVN Commit the file.
The change will not be immediate on the WordPress.org site. But it should be reflected within an hour (based on my experience). And it will be longer until update notices appear in the Plugins admin page of your user’s WP installations.