Making WordPress.org

Opened 3 years ago

Closed 4 days ago

#5901 closed defect (bug) (fixed)

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

Reported by: dd32's profile dd32 Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

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.

Change History (7)

#1 @dd32
3 years ago

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.

#2 follow-up: @kraftbj
2 years ago

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.

This ticket was mentioned in Slack in #meta by adnan007. View the logs.


19 months ago

#4 in reply to: ↑ 2 @dd32
19 months ago

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)

#5 @dd32
12 months ago

In 12587:

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

See #5352.
See #5901.

#6 @dd32
12 months ago

In 12588:

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

See #5901.

#7 @dd32
4 days ago

  • Resolution set to fixed
  • Status changed from new to closed

I think this is fixed.

Note: See TracTickets for help on using tickets.