Changes between Initial Version and Version 1 of Ticket #5645

03/02/2021 07:15:35 AM (3 years ago)

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)

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:

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.

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 10up Github action which deploys any releases I tag on Github to be pushed over to plugins.svn instead.


  • Ticket #5645

    • Property Keywords security UX logging removed
    • Property Priority changed from high to normal
  • Ticket #5645 – Description

    initial v1  
    99Without knowing the technical ins and outs of the Directory system, I've thought of a couple possible pseudocode implementations of this:
    11 ```
    1212if ((stable_tag !== 'trunk' or null) and parsed_stable_tag == 'trunk') send email
    13 ```
    15 ```
    1616if (parsed_stable_tag == 'trunk' and tags/* exists) send email
    17 ```