Prepare 3.x wp.org release

dominic-ks commented 5 months ago

OK, I think the time to merge the current version of this plugin that is live on WordPress.org and the latest master version on GitHub has come, with a view that subsequently the merged version will go live on WordPress.org, and from that point onwards, they shall remain in sync.

This will look like there's a lot of changes here, but really there are only a few things to consider, see summary below of the high level changes with files that contain changes to support each.

Merging these changes with the master branch doesn't change any of the behaviour of the latest version, but does bring the two in line in readiness to go to out.

Automation to publish new versions to wp.org with GitHub actions

NB. this is already in use and the last couple of versions went out using actions.

.distignore
.github/workflows/asset-readme-update.yml (allows updates to assets and readme without new versions)
.github/workflows/deploy.yml (deploys new tags as new versions)
*.png (all the existing wp.org assets)

The changes made in order to reinstate the plugin to wp.org after the security warning relating to firebase

@sun I recall you had some comments previously about the use of wp_kseson static strings, however I cannot find those now so have made now changes to that approach...

class-auth.php
class-devices.php

Changes to provide alerts and warnings to existing users about breaking changes in V3
class-plugin-update.php
class-setup.php
composer.json (added a lib to manage persisting the dismissal of the warnings)
jwt-auth.php
readme.txt

sun commented 5 months ago

Awesome. I'll try to review this tomorrow or early next week. 🙏

AaronWitter commented 4 months ago

Has this been abandoned?

dominic-ks commented 4 months ago

Has this been abandoned?

I hope not! Just waiting for people to be available to review it, hopefully @sun will have some time soon!

sun commented 3 months ago

Note that we should consider merging the following PRs before this one / before creating the wp.org release:

dominic-ks commented 2 months ago

@sun Thanks for taking the time to review this so thoroughly, I've accepted your suggestions and addressed the other points as well. I will also take a look through those other PRs you mentioned before merging those and this one, then hopefully we can move on!

sun commented 2 months ago

All mentioned PRs have been merged. 👌

Question: When are we actually updating the changelog? Only when tagging/creating a release? Or should this be done with every PR?

dominic-ks commented 2 months ago

It's a good question, I guess we don't have a policy, nor one that says when we will tag a new release. On updating the changelog specifically, I think it makes sense to update it on every PR merge, not only will it be easier since we won't have to look back, but also it means that the change log on the master branch will actually reflect what has been added. Perhaps under the title of "current master" or similar, which can then just be changed to the version number once a release is tagged?

Otherwise, I think this is ready to be merged, and I think we should then plan for this to finally go to wp.org. Once merged, the next tag will deploy automatically.

sun commented 2 months ago

Yeah. Typically people are using the major version as the heading; i.e., "3.x.x". After merging changes, their compatibility decides what the next version number is going to be.

This would mean that we'd need to do this before tagging a release.

sun commented 2 months ago

In essence, we should add the following to the changelog in the readme.txt (outside of diff context, so I sadly cannot suggest):

= 3.0.2 =
- Fix: Do not revalidate authentication headers if a valid user was determined already. (#75)
- Fix: Added debugging timeframe before purging refresh tokens. (#93)
- Fix: Fixed unnecessary user account lookup for device listing on user profile page. (#84)
- Fix: Added more granular refresh token validation error messages. (#78)
- Fix: Added integration for new CORS filter hook rest_allowed_cors_headers in WordPress 5.5.0. (#97)
- Fix: Updated Guzzle to v7.8.1 (used in tests only). (#112)

I'd recommend to continue the new versions and actually release the version 3.0.2 to wp.org, so that everyone who was using the plugin from GitHub will see a difference to their currently installed version.

sun commented 2 months ago

Note that I reduced the minimum required maintainer approvals for each PR from 2 to 1 – so you can go ahead and merge this whenever you feel ready 👍

usefulteam / jwt-auth

Prepare 3.x wp.org release #114