[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:                    |
------------------------------+---------------------
Changes (by dd32):

 * keywords:  security,UX,logging =>
 * priority:  high => normal


Old description:

> Hi,
>
> We encountered an issue yesterday when I accidentally triggered the
> release of a broken development version of our Plugin. A full post-mortem
> is available at https://github.com/markcheret/footnotes/issues/55, but 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/`.
>
> We've reviewed the issue and changed our release process to avoid it
> happening again in future, but I'm willing to bet that I'm neither the
> first nor the last person to make such a mistake.
>
> Part of the issue was that none of us received any notice that the SVN
> had defaulted to using the code in `trunk/` (as we usually do whenever a
> new tag or revision is committed), which would have quickly alerted us to
> the fact that something was wrong. I would like to request that some sort
> of fallback notification email be implemented in order to help developers
> to catch such cases.
>
> Without knowing the technical ins and outs of the Directory system, I've
> thought of a couple possible pseudocode implementations of this:
>
> ```
> if ((stable_tag !== 'trunk' or null) and parsed_stable_tag == 'trunk')
> send email
> ```
> or
> ```
> if (parsed_stable_tag == 'trunk' and tags/* exists) send email
> ```
>
> Thanks,
> Ben

New description:

 Hi,

 We encountered an issue yesterday when I accidentally triggered the
 release of a broken development version of our Plugin. A full post-mortem
 is available at https://github.com/markcheret/footnotes/issues/55, but 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/`.

 We've reviewed the issue and changed our release process to avoid it
 happening again in future, but I'm willing to bet that I'm neither the
 first nor the last person to make such a mistake.

 Part of the issue was that none of us received any notice that the SVN had
 defaulted to using the code in `trunk/` (as we usually do whenever a new
 tag or revision is committed), which would have quickly alerted us to the
 fact that something was wrong. I would like to request that some sort of
 fallback notification email be implemented in order to help developers to
 catch such cases.

 Without knowing the technical ins and outs of the Directory system, I've
 thought of a couple possible pseudocode implementations of this:

 {{{
 if ((stable_tag !== 'trunk' or null) and parsed_stable_tag == 'trunk')
 send email
 }}}
 or
 {{{
 if (parsed_stable_tag == 'trunk' and tags/* exists) send email
 }}}

 Thanks,
 Ben

--

Comment:

 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: https://wordpress.org/plugins/footnotes/advanced/

 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
 [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.

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