Streamline PL and standalone plugins release

[thelovekesh]

Currently, when a new PL plugin version gets released two workflows get triggered:

• Deploy to WordPress.org (Deploy Performance Plugin)
• Deploy Standalone Plugins (Deploy each standalone plugin)

But the standalone plugins can also be deployed using the workflow_dispatch trigger which does not require any release to be created. As mentioned by @westonruter, in this case there will be no record for such plugin which are deployed manually on workflow_dispatch trigger - #1033 (comment)

TODO

• Streamline plugin release and release notes.

(More TODOs can be added with ongoing discussion)

[felixarntz]

@thelovekesh What are our options here?

The approach that quickly comes to mind is to create GitHub releases for the individual products and then the workflows act accordingly, e.g. based on the release name. For example, we could make it so that a release named webp-uploads 1.0.6 triggers a deployment of the webp-uploads plugin at version 1.0.6. That's one way.

Alternatively, we could consider having a workflow that even creates the release for us. That would be even more efficient because all information is already present:

• The version number would be in the code and readme.
• The changelog would be in the readme.
  A workflow could extract that and create the release automatically, and then also deploy.

There are probably alternative approaches too. Let's brainstorm and discuss our options a bit, and then make a decision before starting with the implementation.

[thelovekesh]

@felixarntz If we go with creating separate releases for each standalone plugin, we will be bombarded with release entries on the releases page. Another approach that comes to my mind is to keep two release workflows:

• Performance Lab Plugin - The release title can be Performance Lab 3.0.0

  Release changelog example

  Features
  // Futher details.

  Enhancements
  // Futher details.

  Bug Fixes
  // Futher details.

• Performance Lab Features - The release title can be Performance Lab Featutres 1.0.0
  

  Release changelog example

  WebP Uploads - 1.0.3

  Features
  // Futher details.

  Enhancements
  // Futher details.

  Bug Fixes
  // Futher details.

  Speculation Rules - 1.2.0

  Features
  // Futher details.

  Enhancements
  // Futher details.

  Bug Fixes
  // Futher details.

It will help us to keep the release entires minimal and changelogs are better organized.

[westonruter]

Why would it be hard to track release logs if PRs are assigned plugin-specific milestones?

[thelovekesh]

Why would it be hard to track release logs if PRs are assigned plugin-specific milestones?

I meant release entries on the release page. Sorry for the confusion. I have updated the comment above.

[swissspidy]

Since we're talking about releases and deployments here:

What works well for plugins like Gutenberg and Web Stories is to use deployments as the entrypoint for publishing new versions (rather than the release being the entrypoint). For example, if you want to ship a new version of the plugin:

1. Manually dispatch/trigger the release workflow on GitHub
2. Thanks to environment protection, someone needs to approve this "deployment"
3. The workflow then updates the version numbers, changelogs, creates a GitHub release, etc., and uploads the plugin to WordPress.org

Advantage: very easy to use, extra safety due to environment protection, no code changes needed to release a new version.

If we go with creating separate releases for each standalone plugin, we will be bombarded with release entries on the releases page

I wouldn't say "bombarded". It's not like we're doing 1 release a day or so. So I don't think this is really a problem. The "Performance Lab Features" idea is interesting but IMHO a bit overkill.

GitHub releases aren't really the source of truth. People will go to WordPress.org and WordPress admin to install plugins and get new versions.

[thelovekesh]

Before we start, let's also gather info on:

• Are we using the 'n.e.x.t' versioning for all plugins?
• Do we need a release branch for all plugins or just the PL one?

[felixarntz]

@thelovekesh

Are we using the 'n.e.x.t' versioning for all plugins?

I just opened #1118 in that regard. In other words, yes we should. We just can't until the npm run since command has been enhanced to support the other plugins (which is the technical enhancement that issue proposes).

Having to put specific versions on code in PRs before we even know when it will be released or in which versions is a poor experience and requires a lot of manual oversight. It often means we add a version number and bump the plugin version preliminarily. See the new issue for more context.

[thelovekesh]

As discussed in the previous Performance chat, here are the steps we can follow to automate the release along with automating:

• The plugin-name-n.e.x.t milestone name with the plugin-name-x.x.x version and create a new milestone with previous name i.e. plugin-name-n.e.x.t.
• Release branch creation and update the @since tag on the trunk.
• Changelog generation. Instead of manually adding changelog to the readme.txt, we add = n.e.x.t = placeholder and update it with release notes when a new release is created.

Once a release is triggered for a plugin by passing the plugin slug and milestone, the following step takes place:

graph TD;
    A[Trigger release workflow] --> B[Create draft release];
    B --> C[Attach assets to release];
    B --> D[Create release branch, bump version in readme and update n.e.x.t];
    D --> E[Add changelog to plugin];
    D --> G[Create PR with trunk as base];
    G --> H[Attach required information on PR];
    H --> I[Update current milestone];
    I --> J[Create new milestone];

Loading

[swissspidy]

Thanks for putting together a diagram, very helpful!

Why is the draft release with assets created before the version is updated in readme.txt? Why does the workflow create a PR and not just automatically deploy to WordPress.org? Maybe I'm missing something, but IMO we should try to automate as much as possible to remove need for human intervention and errors.