[wp-meta] [Making WordPress.org] #7742: Release confirmations: users are seeing update notifications before an update is available

[Making WordPress.org]

#7742: Release confirmations: users are seeing update notifications before an
update is available
------------------------------+--------------------
 Reporter:  barry.hughes      |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:
Component:  Plugin Directory  |   Keywords:
------------------------------+--------------------
 We recently enabled release confirmations. Unfortunately, after committing
 a tag to SVN (but before we update the stable tag), users are seeing
 notifications that the new version is available. In fact, it is not.

 This has happened over a number of recent releases (for WooCommerce) and,
 during one of those releases, we were able to replicate seeing the update
 notification ourselves on a staging site (see attached screenshot). We've
 been in touch with plugins at wordpress.org and on
 [https://wordpress.slack.com/archives/C1LBM36LC/p1722886929952579 Slack],
 but it felt like it was worth logging a ticket here—as this is causing
 confusion and eroding trust (some customers believe we have shipped a
 release, only to quickly 'pull it', which isn't what is happening).

 I'll copy here the summary shared by my colleague in Slack, for easier
 reference.

 > Hey team! A few days after having enabled release confirmation for the
 WooCommerce plugin, we started noticing that committing a tag to SVN would
 not only create the pending release but also update the plugin version
 right away. I'd like to share some notes on this behavior and would
 appreciate your guidance. Happy to move this to a different channel or
 submit to Trac if that's preferred.
 >
 > - Timing seems to indicate this started happening after
 [https://meta.trac.wordpress.org/changeset/13874/sites/trunk/wordpress.org/public_html
 /wp-content/plugins/plugin-directory/cli/class-import.php this change]:
 specifically that, if RC is enabled, `$version` gets overwritten with the
 tag name (L171) and then persisted as the version to plugin metadata
 (L457).
 >     - This, in particular, results in the plugin page displaying a
 version that is not the sable one as "Version" and also the update being
 offered to WP sites. Luckily, the download link in the
 `plugin_information` response still uses the stable tag, so even if
 someone "performs the update" it doesn't truly install a non-stable
 version.
 > - Our workflow might be a bit different in the sense that we commit the
 SVN tag and trunk together when releasing a new version, but only update
 the stable tag after a bit.
 >     - Despite this, we feel that committing a tag shouldn't necessarily
 make it the latest version immediately (more-so if it's not the stable
 one), and that wasn't the case in a previous iteration of the RC feature.
 >     - In our multi-step process, once we finally update trunk with the
 new stable, the import process takes care of returning things back to
 normal (as `$version` no longer gets overridden and it uses the version
 header in the stable tag).
 >
 > The above is my take after having looked at the code for plugin-
 directory in the meta SVN repo, but I might be missing something due to
 unfamiliarity. Appreciate any feedback you could share. Thanks again!
 >
 > [...]
 >
 > I believe things go back to normal as soon as the release is confirmed
 (regardless of stable tag in trunk) because RC approval triggers
 import_from_svn() again but this time the release already exists and so
 the code
 [https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html
 /wp-content/plugins/plugin-directory/cli/class-import.php#L169 doesn't
 enter the if() branch where $version gets overwritten]. Instead, it
 updates meta with version from the headers in the stable branch, which is
 ok.

 I hope the above gives some insights into what might be going wrong. Let
 us know if we can provide any further information—release confirmations
 are a great idea, so we're keen to seem them working well.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/7742>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org