Plugin 'Development Release' ZIPs not updating with Release confirmation enabled

[dd32]

It appears that some plugins are experiencing problems where the trunk ZIP file (plugin-name.zip) is not being updated with the latest changes in trunk, when they have release confirmations enabled.

The release ZIPs (tags) are created properly, but the trunk ZIP appears to be stale as of when the plugin enabled the feature.

The trunk ZIP should always be updated, unless it's being used as the stable tag.

[dd32]

In 11238:

Plugin Directory: When release confirmations are enabled, always build the trunk plugin-name.zip zip.

When release confirmations are enabled, trunk can never be set as the stable tag, so it's always safe to build the trunk zip.

There's still a limitation here - If a commit introduces a new stable release AND modifies trunk in the same commit, the trunk ZIP won't be updated until the release is confirmed.
It'd be nice to still rebuild the ZIP in that case, so a follow up change may still be required.

See #5352.
See #5901.

[kraftbj]

Related, it appears that pre-release versions are not built and not able to be confirmed.

Example we hit with Jetpack:

• we update trunk weekly.
• we cut an alpha tag so some testers/early-adopting platforms (e.g. 10.8-a.1).

The trunk zip (jetpack.zip) built and was accessible, but the pre-release version did not ( jetpack.10.8-a.1.zip ) and there was no way I could find to confirm the pre-release tag.

[dd32]

Replying to kraftbj:

Related, it appears that pre-release versions are not built and not able to be confirmed.

This was brought up again in ​https://wordpress.slack.com/archives/C02QB8GMM/p1666695206881219

In a way, this is intentional.. A release can't be confirmed if it won't be released, but the release confirmation is only triggered by attempting to make a release.

It could be updated to trigger on any new tag creation, and allow confirmation of that tag, but then there'll also be cases where someone confirms the tag creation but it's not actually released, as the Stable Tag was never updated.

I see a few options we could do:

• As above, always trigger confirmation on new tag creation (NOTE: tag alterations after confirmation would not be possible once confirmed..) and allow stable tag to be set afterwards
• Always build alpha/beta/rc versions as noted by -a* or -beta* or -RC* (Doesn't help when they're after a pre-release of an actual release)
• Always build the ZIPs, and move Release Confirmation to the step which is required to mark it as the stable release. That wasn't done originally to reduce complexity and to ensure that no ZIPs built could bypass the confirmation, ie. we don't want to serve non-confirmed code at all.
• Always build the ZIPs, but limit download to plugin committers (This seems like it'll cause problems)

[dd32]

In 12587:

Plugin Directory: Release Confirmations: Allow for releases to be confirmed (and built), that are not the stable version.

See #5352.
See #5901.

[dd32]

In 12588:

Plugin Directory: Release Confirmation: Allow building a older branch release without confirming the next-stable release.

See #5901.

[dd32]

I think this is fixed.

[dd32]

In 13875:

Plugin Directory: Release Confirmation: always rebuild trunk.

See #5901;