Handling updates and new default features

[mboynes]

Description

I admit there's some level of FUD in this topic, but I'll try to keep it as action-focused as possible.

Updating Alleyvate on a site carries a level of risk. Each update will (almost certainly) include new default features, which will add, remove, or modify some aspects of WordPress core. These may be things about WordPress that a site uses, whether we realize it or not. As a for-instance, say the plugin disables "sticky posts" at some point in the future. As far as I know, we don't use that anywhere, but it's possible one of our clients does leverage that feature.

All this to say, every Alleyvate release is (again, almost certainly) a "breaking change" for WordPress. Below are some assorted recommendations that come to mind for me. Let's discuss these and others to codify some process for updating Alleyvate on a site.

1. Alleyvate must follow a proper (semver) release cycle, and sites must only install releases (never install via the main branch).
2. Releases must include a detailed changelog which includes an upgrade guide. The upgrade guide should call out specific things to check and include copy-pasteable code to disable the feature.
   • Example: When #35 is released, it should recommend that a developer check the comments table to be extra certain that a site doesn't use, and hasn't ever used, comments. It should also include a note "To opt out of this feature, add add_filter( 'alleyvate_load_disable_comments', '__return_false' ); and/or add_filter( 'alleyvate_load_disable_trackbacks', '__return_false' ); to your codebase."
3. Alleyvate must not be updated blindly on a site.