Add extension compatibility list

[colemanw]

Overview

Extensions whose functionality is now redundant with core may cause problems if left installed. This PR will:

• Automatically disable obsolete extensions during core upgrades.
• Filter out obsolete extensions from the list of downloadable extensions.
• Ignore obsolete extensions when considering dependencies.

Technical Details

The extension-compatibility.json file is a very open-ended format. For now it just contains one type of information but we can easily add to it if we want to use it for more purposes.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[colemanw]

@totten can you please review this one?

[totten]

Weehoo tests!

[colemanw]

@totten I made your suggested change to static-cache the file contents.

[colemanw]

@civicrm-builder retest this please

[colemanw]

@totten this is passing - any other feedback?

[MegaphoneJon]

One question - does this format allow someone to specify a particular version of an extension as obsolete/incompatible? While I realize the immediate use case is to mark an entire extension incompatible, I imagine the more common use case is, "myextension 2.x won't work with CiviCRM 5.13+, upgrade to myextension 3.0". On first glance it seems like this isn't supported but I could be wrong.

[colemanw]

This format is pretty open-ended. It doesn't prevent us from adding that info in the future (along with the logic to handle it), but it doesn't currently do so.

[totten]

(CiviCRM Review Template WORD-1.2)

• General standards
  • (r-explain) Pass
  • (r-user) Pass
  • (r-doc) Soft pass: This should probably be documented somewhere, but that can be post-merge. Altho... there's no Gitlab issue? Tangentially... I think we also wanted to update the extdir infra to consume this? Prob good to have the issue to track other bits.
  • (r-run)
    • Soft issue: Tested in CLI and web UI. Noticed some formatting oddities - screenshot in other comment. But I'm not gonna push on that hard.
• Developer standards
  • (r-tech) Pass: As long as individual changes to extension-compatibility.json are vetted, seems fine.
  • (r-code) Debatable Issue: I re-read this and realized the new function getCompatibilityInfo() was in CRM_Extension_System. This class is a bit unusual stylistically -- it's neither a list of static methods (like BAO code) nor is it container-ized (b/c it predates the Container and b/c bootstrap-sequencing issues make it hard to move there). Rather, the "extension system" (as a whole) is a singleton, but it has many properties initialized on-demand. You can cherry-pick totten@5391212 to make this follow the same code-style.
  • (r-maint) Pass: New behavior <=> new test. 👍
  • (r-test) Pass
• Other
  * (rg-pkg): In distmaker/dists/common.sh, there's a whitelist of files to include in the tarball (dm_install_core). I wasn't able to do a distmaker test locally -- distmaker crashed. The distmaker crash is probably happenstance of my local network/system, but I still think one needs to explicitly flag new top-level files.

[colemanw]

@totten I've added the new json file to the distmaker whitelist. Good catch.

[totten]

OK, I'm merging.

Strictly... I've got some more reactions on the r-code style discussion, but the effort to discuss feels out-of-proportion, and Coleman pointed out a plausible reason for the exception. The style discussion is starting to feel like a nuisance that's holding up an otherwise useful change. I'm inclined to merge -- with an understanding that we might revise it on stylistic grounds (but we don't have to).

[petednz]

Any chance that a warning that it will disable obsolete extensions could be offered before it runs the upgrade. just thinking of a situation where a user has an extension and if they knew it was about to be disabled might instead holding off upgrading core?

[colemanw]

@petednz yes it does display a warning prior to the upgrade.