[wp-meta] [Making WordPress.org] #5645: Feature Request: Update on reversion to `trunk/`

[Making WordPress.org]

#5645: Feature Request: Update on reversion to `trunk/`
------------------------------+---------------------
 Reporter:  rumperuu          |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+---------------------

Comment (by rumperuu):

 Replying to [comment:1 dd32]:
 > Hi Ben,
 >
 > > in short it was due to me not realising that changing the ‘Stable Tag’
 field to the development version (2.5.9d1) in trunk/readme.txt would cause
 the WP Plugin Directory to parse it as a new version, look for the
 corresponding tags/2.5.9d1/ and, upon failing to find it, revert to
 trunk/.
 >
 > May I ask, what did you expect would be the result of this? For simply
 no change to occur?
 > (Do read on, I'm actually okay with that behaviour and it's something
 that's been discussed not-on-trac)

 I didn't expect the versioning info in `readme.txt` to have any effect,
 just as the version number in the Plugin base file docblock doesn't
 (https://plugins.svn.wordpress.org/footnotes/trunk/footnotes.php). Coming
 from a string of Node.js projects, I expect I assumed the only important
 version number was stored in some sort of config file like `package.json`
 or `composer.json`, or that `trunk/` was for dev. versions and `tags/*`
 was for releases (as this is how this particular Plugin is laid out, but I
 see that there is no necessity for other projects to use `tags`).

 This behaviour ''is'' mentioned in the Plugin Handbook
 (https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-
 txt-works/#how-the-readme-is-parsed), but only as a one-liner in the
 second paragraph of the section of how `readme.txt` is parsed. Not
 realising that `trunk/readme.txt` ''would'' be parsed, I didn't think to
 look at ''how'' it might be parsed.

 > > but I'm willing to bet that I'm neither the first nor the last person
 to make such a mistake.
 > You're definitely not the first, there's been a few cases where larger
 plugins have had the same thing happen, where `trunk` was packaged as the
 tag didn't get committed in the proper format.
 >
 > But I also know several plugin authors who rely upon the behaviour.
 >
 > You may want to enable Release Confirmations for your plugin, #5352, you
 can do that here: https://wordpress.org/plugins/footnotes/advanced/

 Ah! Definitely a good idea, thanks for the tip.

 > As part of that, a few of us discussed if disabling plugin releases from
 trunk entirely would be viable, #5484 is a step towards that.

 I think allowing releases from `trunk/` where ‘Stable Tag’ is either
 ‘trunk’ or nonexistent should be fine (and disabling it would presumably
 break those projects you mentioned that rely on the behaviour), but having
 it fallback to `trunk/` when it can't find `tags/stable_tag/` is a footgun
 waiting to happen, especially as it is currently silent. I would expect a
 non-`trunk/` stable tag that did not have a matching folder in `tags/` to
 be considered an error and the last-known-good version to be reverted to.

 > Another thing worth noting, is that since Github is your primary
 development platform, syncing every commit to plugins.svn might not be
 needed, and partially lead to this situation. Personally I use the
 [https://github.com/10up/action-wordpress-plugin-deploy 10up Github
 action] which deploys any ''releases'' I tag on Github to be pushed over
 to plugins.svn instead.

 Thanks for the heads-up, we've only just started shifting over to GitHub
 so I've still got the release process workflow to hammer out.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5645#comment:2>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org