Problem/Motivation
See parent issue, #3104922: Guard against changes to Scaffold Plugin that might cause upgrade problems .
The plugin class is always instantiated by Composer before any part of the plugin runs (activate in the plugin class is the first thing that runs). Once the plugin class is loaded, it won't change, even if the rest of the plugin code is updated. Because of this dynamic, sometimes the solution is to move more responsibilities into the plugin class.
The main weakness is going to be the contract between the plugin class any any other class that it instantiates before a "post" event (e.g. post-update). Any method of any such class called by the plugin class must be frozen forever. If it is not, users will have to know to run composer update --no-plugins when they upgrade that plugin from the older version to any new version with a new API.
When we analyze the other plugins by this criteria, we see that:
The ProjectMessage plugin only has "post" events, and does not instantiate any objects in its activate method. Unless this changes, this plugin is going to be safe to update. This is also a simple plugin, so it should not have a great need to change in a way that would make future updates dangerous.
The VendorHardening plugin has both "pre" and "post" events. It would be really difficult to avoid instantiating any objects until the "post" events are called. However, the VendorHardening plugin also has very few classes: just a file security class, and a config class. As long as the API for these classes never change, the VendorHardening plugin should also be safe to update moving forward.
Proposed resolution
Extend the test from the parent issue to a build test so that we can have upgrade tests for all of the plugins, to avoid the possibility that someone might unwittingly make an unsafe change to some plugin.
Remaining tasks
tbd
User interface changes
None
API changes
None
Data model changes
None
Release notes snippet
tbd