Bump version up to 0.8.2

[ouikhuan]

Bumping version up to include latest changes:

• Update compatibility tested-up-to to WordPress 6.4.2.
• Update doc URL references.
• Adjust workflow triggers.

[jrfnl]

None of these are user facing changes warranting a new release.

[ouikhuan]

That's correct, so we're releasing it with a patch version here. Otherwise, if old changes are merged and not shipped with a version bump, the changes like Tested up to and assets won't be able to porting over to the SVN directly in the future. Is there a better way to resolve this?

[vishnugopal]

When we first took up importer maintenance, several WordPress releases had passed by and the importer had an out of date notice on the plugin page. Verifying compatibility and releasing plugins with new tested up-to versions works well if we do it for every WordPress release, and that's what we'd like to do here.

What is the alternative you suggest to keep supported importers up-to-date on the plugin page? 🙇🏽

[jrfnl]

we're releasing it with a patch version here

A patch version is still a new release.

the importer had an out of date notice on the plugin page

IIRC the "Tested up to" version on which that banner is based comes from the SVN trunk version of the plugin.

As long as the commit which updates the version is pushed to trunk, there is no need to release a new version to bump that header.

What you are doing is version inflation without benefit for end-users.

[vishnugopal]

I think the Github workflow for this repo won't allow us to commit to SVN directly without a release bump, but let's see what we can do to get around this.

cc @dd32 for help 🙏🏽

[jrfnl]

@vishnugopal That would be a good reason to adjust/improve the workflow. Not a good reason for version inflation.

[vishnugopal]

I respectfully disagree. I think the benefit for end users here is that we're testing and verifying compatibility with the latest WordPress releases. But I'll defer to folks like @dd32 who have more experience releasing things like this.

[dd32]

IIRC the "Tested up to" version on which that banner is based comes from the SVN trunk version of the plugin.

This isn't correct, unfortunately a full release is required to bump this field, which is my biggest gripe with how others (read: not-the-plugin-directory) treat the field.

Unfortunately due to "security" plugins, it's also become "good practice" to release a new version at least once a year, even without any changes, as otherwise they start complaining "you're using a possibly no longer supported plugin". Basically trying to justify their existence through fear generation. (Yes, I know it's NOT a good practice)

While we've looked at adding a feature on the plugin directory to specify the tested-up-to without any code changes, unfortunately Core now includes things that use this (which I disagree with, and requires a plugin update to affect), which has also added an additional location for the header that we don't yet support.

https://github.com/WordPress/wordpress-develop/blob/24531a9afc8ef75822da45b85c147b492674e715/src/wp-admin/includes/class-wp-plugin-install-list-table.php#L813

echo '<span class="compatibility-untested">' . __( 'Untested with your version of WordPress' ) . '</span>';

EDIT: Please disregard the final comment here, it turns out I had misremembered / midunderstood a core change, the quoted code is specifically for the install-new-plugin list. so a way for a plugin author to bump tested-up-to without a plugin update would work for that code.

[vishnugopal]

Thanks @dd32 based on your comments, we are going ahead and releasing this new version.

[vishnugopal]

Works with the latest WordPress version, approving!