(This note is subject to revision)
I didn’t want to make another release just two days after 1.9.25. After discussing it a bit, we decided to launch a fix, since the problem was too serious for a significant amount of users (me included :) . The amount of work for releasing a new version is basically the same than releasing a fix, and I took an extra care to refine and tighten the necessary steps to publish it. It implies several deployments to test sites, (local and living ones) and several (and always growing) unit tests.
In all the process, I found something I didn’t see until this version and I guess is part of the plugin’s inheritance. If you see the plugin’s readme.txt you’ll find something like:
=== NextCellent Gallery – NextGEN Legacy ===
Requires at least: 3.5
Tested up to: 4.1
Stable tag: trunk
Let’s focus on the word trunk. So far I know , when trunk/readme.txt is modified, the repository triggers a ‘package assembler’ (creating a zip file with the plugin files) and making it ready to be downloaded for WordPress installations. Stable tag is a pointer to the ‘folder’ where the packager get the files to make the zip files.
Then, ‘Stable tag: trunk’ points to the trunk folder to make the zip release.
Let’s take another example with Statcomm plugin , another plugin I made some time ago:
=== Plugin Name ===
Contributors: WpGetReady / Fernando Zorrilla de San Martin
Donate link: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=KZPB2M355392Q
Tags: stats, statistics, widget, admin, sidebar, visits, visitors, pageview, referrer, spy, multisite, traffic
Requires at least: 3.3
Tested up to: 3.6.1
Stable Tag: 1.7.70
License: GPLv2 or later
In this case, there would be a branch on the repository (branches/1.7.70) where the code is located and it is used to make the release. Notice that ‘trunk’ and ‘branches/1.7.70’ are completely different ‘folders’ and code versions.
Those examples leads to different deployment strategies. In the first example (the trunk tag), just when I commit the files to the trunk, the package assembler is triggered (suppossing readme.txt is changed) . I usually make a branch in order to have releases in case of need, but notice this is optional, which could lead a some sort of ‘disorder’ if we forgot to branch it. In the second example, we first make the branch and after that, deploy to the trunk (or just modify trunk/readme.txt) to trigger the packager. In this case the branch is mandatory.
As always, it’s your choice to select one strategy over another.
Revolving around readme.txt
While readme.txt isn’t changing, we can safely add, modify or delete code on the repository. Those changes won’t be reflected in the current version until we change readme.txt.
If you are a plugin programmer, just pay attention to your Stable Tag on readme.txt and make your strategy according to that.