3.0.3 release

[dominic-ks]

@sun as was mentioned here, yes, it'd be good to release this. I guess we don't have a process for releasing, if you have any thoughts, please say, otherwise, I'm just putting this pull request in to update the version tags and if we agree, and it's approved then whoever merges can also just tag the release which will trigger it to go to wp.org. Happy with that?

[dhm-msd]

Any news on releasing 3.0.3 ?

[sun]

@dominic-ks Oh, I'm so sorry, this fell off the radar! – Yes, let's do this! 👌

Do we have a documentation somewhere what the steps for preparing, creating, and publishing a release are? Because the current PR does not update the plugin version constant:

jwt-auth/jwt-auth.php

Line 22 in 25df387

define( 'JWT_AUTH_PLUGIN_VERSION', '3.0.1' );

I didn't check other places, this one was just visible in the diff context.

I'm usually documenting this step-by-step (so that a monkey could do it) for all the projects and plugins I'm maintaining elsewhere, because release procedures are usually special and frequently forgotten about if you only do it once per year or so… 😉 I actually don't know how it works for the jwt-auth plugin currently - I believe you added a GitHub Action but it did not work the last time?

With regard to the general question of who can approve/create releases – I'm just seeing myself as a contributor to this plugin as well. 😅 I would argue in favor of common sense – it would be wise to discuss security related changes in-depth in the PRs before merging them, but other/smaller changes can be merged and released as with any other plugin. And if there are security related changes in master already, then they should be fine to release, too. Does that make sense?

Admittedly, looking at the current list of open PRs and the nature of this plugin, the majority of them are related to site security or reliability, either directly or indirectly, so there might not be so many simple changes after all… 🙈 – but yeah, I guess it boils down to having a clear consensus on all PRs that could have an impact on security or a potential change in behavior for all the existing sites in any way.

[sun]

Oh I remember, you explained part of the process a while ago in #121 (comment)

[dominic-ks]

Hey @sun, yes, I'm in favour of allowing small changes to just be published. We may also want to consider a period of time as well, so that if one of the contributors wants to put a change out and others are not available to review in X time that we just go for it. Obviously all of us have other things going on, but I don't think we should hang back from pushing changes out for long periods as we have done now.

I think that some of the workflow runs have been archived or something, it's just showing the 3 failed at the moment, but the latest releases on wp.org have definitely come through the automated action.

I can look at drafting a file to document the process for releasing unless you have one from another project we can adapt...?

[sun]

Here is a random one I found using a different release process than the GitHub action, but anyway, this just serves as an example for the level of detail and start and end – a good place would be the repo's Wiki:

---

Update

1. Ensure you have Subversion installed. If not, install it with brew:

   brew install subversion

2. Ensure wp-release script is installed. If not, follow the installation instructions.

3. Bump the plugin version in all files (plugin.php, README.txt, package.json).

4. In the changelog in readme.txt, insert a new release version heading directly after the dev/master version heading.

5. Commit and push your changes, and merge the PR into master.

6. Run wp-release.sh.

   ⚠️ You might need to edit wp-release.sh and change the READMEVERSION variable so that README.txt is uppercase.

   1. Paste svn password of wordpress.org user from 1password.

7. Confirm that you see the new release in the plugin directory; e.g. on https://wordpress.org/plugins/gallerya/

[dominic-ks]

OK, back to get this covered off. Looking at what our actual release process is, I feel that we can cover it just adding a few lines to the readme:

Release Process

This plugin is deployed to WordPress.org via GitHub Actions when a tag is pushed, which can be carried out by any plugin contributors:

1. Update version numbers in jwt-auth.php and readme.txt, and add the new changes under Changelog.
2. Commit your updates and open a pull request for review.
3. After merging, create and push a tag matching that added in step 1. Pushing the tag runs the Deploy to WordPress.org workflow, which publishes the plugin automatically.

[dominic-ks]

@sun In reference to your comment here:

• Fixed string translation is invoked before gettext domain is registered. #139 (comment)

I don't believe we have anything that would update the changelog automatically, I believe we previously discussed that it should be updated with PRs being merged to master with a placeholder version, and that version would be set on tag / release.

[sun]

Blocked on:

• Fixed infinite recursion in determine_current_user caused by get_user_locale(). #142

[danielpost]

In case it wasn't already on your radar, make sure to update Tested up to in the readme.txt file. Currently the plugin page on .org has a big warning banner, even though the plugin still works with no issues.

If it helps, I'm using the same Github Action in my plugin Autoblue, and it's fairly well documented. I have a script (bin/release.sh) that handles some of the more tedious steps, and the GH action takes care of the deploy to .org. The readme has step-by-step instructions for handling a release, which might be helpful.

The action runs whenever a new release (tag) is published, and the last one in this repo seems to be 2.1.0, which might explain why it hasn't run in a while.