Tracking 1.4.1 release

[kasparsd]

Tracking all pull requests that must be merged for the 1.4.1 release since I don't have access to the milestones feature:

• Ensure the correct cache type for DID document #504
• Account for package metadata that doesn't include filename when deriving hashed filename #496
• Remove leftover ( new Updater\Updater( $did ) )->run(); call during DID ajax install #509
• Match the WP core behaviour in parsing plugin file header fields did-manager-wordpress#15
• Bump fairpm/did-manager-wordpress to ^0.0.8 #510

Optional (also low impact, high value):

• Consistent phpunit runners for local and CI #493
• Allow installing via Composer #506

[namithj]

did-manager-wordpress version bump pr : #510

[Ipstenu]

What we need to test for confidence in this:

• Can we install with a DID?
• Does updating via DID keep the same plugin slug when installed from (because the folder slug is different in each) ...
  • Direct from GitHub
  • Via DID (install via plugins tab)
  • GitUpdater
  • WP Cli
• Will it show updates when plugin folder is 'different'?

The big question is how to test this without releasing a new version.

We also need an automated way to test these so we don't have to rely on human brain.

[namithj]

The way I am testing is as follows

• Fork Fair-Plugin with a new name
• Create a new DID for the forked plugin
• Try doing a release
• See how the plugin updates.

[Ipstenu]

We need more ideas to test this so we don't have to edit code.

• Beta Tester plugin
• New Branch selection
• Manually edit the version to trick WP

We may need a batch of WP plugins that are a version old to see what happens with other plugins

[kasparsd]

@Ipstenu I created this repository for testing most of these workflows https://github.com/kasparsd/fair-testing

The idea is that you have a dedicated WP environment where we have FAIR connect at various versions (including fake-downgrade versions) to test the update flows. The FAIR connect plugin can be copied in from either a local FAIR clone or something like that.

Don't ask me how I know that FAIR connect on update will overwrite itself, including all the unmerged and unpushed branches under the .git directory of that plugin.

The only thing it doesn't do is to fake the various FAIR repository responses for missing/incomplete/invalid field types and values.