Opened 5 months ago
Last modified 2 months ago
#7783 new defect (bug)
Create a Releases page for every plugin.
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | has-patch |
Cc: |
Description (last modified by )
Proposal
Add a 'Releases' tab to each plugin to centralize release features and information, and promote best practices.
Context
Release related functionality and information appear in different places within the plugin directory. Some examples include:
- Release confirmations have their own page.
- Readme.txt importing issues are displayed as banners on the plugin homepage to authors.
- Releases are downloadable in a plugin's Advanced View (Provided tags are used).
- Changelog is displayed in the "Development" tab. (Varies from plugin to plugin)
There are also some forward-leaning features for plugins that will also need a home that may be relevant:
- Provide a GitHub Integration for Plugins
- Linting for Plugin Submissions + Filters for Plugin Directory Searching
- Add a "Tag and release" button
- Reporting Security vulnerabilities in plugins
What should/could the page include?
- Should include release confirmations.
- Should display import issues with specific releases.
- Should allow users to download older versions (although not promote it).
- Should strongly encourage the use of
/tags
for releases. - Could allow users to manually create releases using a zip/GitHub integration (bypassing SVN which is a barrier for some users). Edit: No changes to how code is stored or deployed. SVN will still be the underlying version control system :).
- Could display plugin check results.
- Could display known Common Vulnerability and Exposure information to plugin authors.
- Could provide release and/or performance related stats.
- Could provide changelogs for respective release.
- Could link to changesets to help user track changes between releases.
- Could make it easy to test previous versions in playground.
- ... I'm sure there's more things we can add to make it more valuable.
I'm curious what ya'll think. I'm not a designer but I've attached is an early, lo-fi version of what's in my head.
Attachments (3)
Change History (21)
#1
@
5 months ago
These look great Steve, I'm excited to see this come together. Some thoughts:
- It might be useful to display the required WP versions in the list of older versions, so it's easy to find the most recent version compatible with a particular WP site.
- For "create a release", I imagine the zip link thing would often be used with GH releases. Do you think it's worth integrating that more closely? Or would that be a future work thing?
Also, I looked into what the "see changes" links might go to. Trac does support a diff view between branches that's sometimes useful:
For certain very large plugins with busy build processes, that view is likely to either time out or show something of little use. But it's probably fine as a starting point.
#2
@
5 months ago
Hey! That's seems a good stepforward for increasing security in releases, code review with PCP and make it easy for developers to create a new release.
Some suggestions:
- I suppose that PCP results will be only visible for the owner and committers.
- And I'd add as well PHP compatibility in that list of releases. That would be helpful to avoid conflicts.
Does the PCP checker will block if there are errors in the release? that could be important for ensuring security in releases.
#3
@
5 months ago
Love the idea and would definitely make everything clearer for users.
Can I suggest some options to filter/sort the list of releases by latest and PHP version so that users can identify which one they need?
Additionally, adding some kind of warning before downloading a version that is older than say X years or the last X versions of WordPress?
Adding a manual release option may require additional server processing to open the zip and scan it etc. and would deviate from the SVN system in place. The SVN system also adds another layer of security to plugin releases.
#5
@
5 months ago
This looks fantastic @dufresnesteven. I've had plugins on the repo for over a decade and did not even know about Release confirmations 😅
This ticket was mentioned in PR #376 on WordPress/wordpress.org by @dufresnesteven.
5 months ago
#6
- Keywords has-patch added
Experimenting with https://meta.trac.wordpress.org/ticket/7783.
#7
@
5 months ago
Sounds pretty good, can't wait to see at least some of this implemented! :)
Could allow users to manually create releases using a zip/GitHub integration
A bit unsure what this is/how that would work? Will it be pulling plugin's source (assuming alpha/development version) from GitHub and zipping it on wp.org and letting the user download the zip? That probably won't work for some (many?) plugins that need to be built?
Also, unsure what would be the role of wp.org here? If the plugin authors want to make an alpha version available to users, why not "release" it on GitHub instead? Imho plugins that are developed on GitHub should always have a link to their repo there from the plugins screen on wp.org. Seems that would be more useful to users?
#8
@
4 months ago
A bit unsure what this is/how that would work? Will it be pulling plugin's source (assuming alpha/development version) from GitHub and zipping it on wp.org and letting the user download the zip? That probably won't work for some (many?) plugins that need to be built?
No, it would pull in the zip file (or the source), prepare it to be committed to the repo as a new tag, and prompt the author for confirmation before doing so.
That probably won't work for some (many?) plugins that need to be built?
That's the reason why the initial designs don't include GitHub integration. We are not sure how to handle that. Instead we could receive a zip artifact from a public build server and pull that in. That is depicted in the current designs. If that isn't deemed valuable, we can rethink that.
Also, unsure what would be the role of wp.org here? If the plugin authors want to make an alpha version available to users, why not "release" it on GitHub instead? Imho plugins that are developed on GitHub should always have a link to their repo there from the plugins screen on wp.org. Seems that would be more useful to users?
Yep, alpha versions should not be uploaded to wp.org. Those who develop & release on GitHub are still able to. Those who use GitHub actions that push to wp.org SVN will still work the same. However, it's better UX to have consistency in where to locate releases on wp.org. Finding a release and relevant information for plugin X should be the same for plugin Y and I would suggest we avoid the pattern of linking users away to GitHub repositories or company websites to download files or understand what recent changes were added to the plugin that they use.
#9
@
4 months ago
Hello @dufresnesteven
At the plugin review team, we are discussing options for linking to the source code in the readme file. We think the release tab could potentially be a great place to add it, next to each release.
Here is the proposal draft (it's a private link; let me know if it's restricted for you): https://github.com/WordPress/plugin-review-internal-scanner/issues/170#issuecomment-2353388327
#10
@
4 months ago
A couple of additional notes from Plugin Team meeting
Should strongly encourage the use of /tags for releases.
This is actually not needed since now that Release Confirmations are required to release from WordPress.org it is not possible to release from trunk anymore.
Could link to changesets to help user track changes between releases.
This seems more like a developer feature, and exists currently on the link on the developer tab. I think it'd be better to keep it there.
Could provide changelogs for respective release.
I like the mockup of this in the screenshots, however, WordPress.org doesn't have a standardized format for the changelog section of the readme.txt file. I don't see that as a blocking issue, but rather something we simply just need to do. We could create a standardized format and then notice plugin authors via email + Make & add a rule for it in Plugin Check as well as update the readme validator scripts to check for the new format, but we'd need to come up with one first.
#11
@
4 months ago
@milana_cap Thanks for sharing that. I can see why this may feel like a candidate for that information. With that being said, it doesn't quite fit with the way I'm envisioning it. Each version is a snapshot in time and to me, the changes between versions are the most important details to communicate. Information that is likely to persist across versions isn't something I consider particularly relevant for most users in this view.
However, I would be in favor of moving the controls from the "Advanced view" to a "Settings" tab and adding these details in the "Advanced view" and exposing them somehow to the main plugin "Details". Noting that @dd32 and I discussed the "Settings" tab idea a few months back.
#12
@
4 months ago
@chriscct7
This seems more like a developer feature, and exists currently on the link on the developer tab. I think it'd be better to keep it there.
I agree and disagree. It's a feature for a developer but one that is maintaining a website and not one looking to contribute to said plugin. I also don't see an easy way to see the changes between versions in the "Development" tab.
I like the mockup of this in the screenshots, however, WordPress.org doesn't have a standardized format for the changelog section of the readme.txt file. I don't see that as a blocking issue, but rather something we simply just need to do. We could create a standardized format and then notice plugin authors via email + Make & add a rule for it in Plugin Check as well as update the readme validator scripts to check for the new format, but we'd need to come up with one first.
Agreed. We don't have anything in place to do that consistently at the moment.
This ticket was mentioned in PR #403 on WordPress/wordpress.org by @dufresnesteven.
4 months ago
#13
Related https://meta.trac.wordpress.org/ticket/7783.
This PR adds the "Releases" tab behind a feature flag show_release_beta
so we can work together on the site.
@dufresnesteven commented on PR #376:
4 months ago
#14
replaces by https://github.com/WordPress/wordpress.org/pull/403.
This ticket was mentioned in PR #407 on WordPress/wordpress.org by @dufresnesteven.
3 months ago
#15
Related https://meta.trac.wordpress.org/ticket/7783.
This PR adds the "Releases" tab behind a feature flag show_release_beta
so we can work together on the site.
@tellyworth commented on PR #407:
3 months ago
#16
@StevenDufresne I think the CPT code is kinda-sorta functional, thought not really hooked up to anything yet.
I've added a bin script you can use to (re)generate CPT entries for a specific plugin for testing purposes:
php bin/update-release-cpt.php --plugin=debug-bar
Next step is to properly hook this up to the main Plugin Directory class, and add some internal and REST APIs.
@tellyworth commented on PR #407:
2 months ago
#17
With the last commit f5cc81a I was thinking about how to backfill in production, and how to eventually deal with migrating and replacing the releases
postmeta.
Assuming we want to replace the postmeta with CPTs, it would be fairly straightforward to replace functions like Plugin_Directory::get_releases()
with wrappers for Plugin_Release::get_releases()
etc. And adapt Plugin_Directory::prefill_releases_meta()
to backfill CPTs from svn data. Then update anything that depends on the postmeta (like Release Confirmations) to work with a post object rather than the simple postmeta array format.
The main difficulty with that is migrating in such a way that everything continues to work smoothly - ie plugins that haven't been backfilled smoothly can still have releases confirmed.
I think the best way to manage that would be:
- Have the import code backfill CPTs on the first trunk commit for each plugin. That way we'll gradually backfill actively developed plugins first. (Already done in f5cc81a)
- When we're happy that the backfill data is good, run a one-time script to backfill other plugins. Could be done from a sandbox.
- Then, replace the code to swap in CPTs for postmeta as outlined above.
I guess I could write and test a gated version of (3) so that it's ready to go and we just have to flip a switch.
Release Confirmation page.