I have a fork of the Contribution plugin that I am modifying for specific use cases on my site.
I have some changes that will require altering the Contribution Type element table (basically adding an “instructions” column, sort of like the “comment” column in the standard element table, so that on the admin side you can give instructions aimed at users of the contribution form without changing element descriptions and comments elsewhere).
Obviously I’d like to do this without uninstalling the plugin entirely and losing all the tables.
I’m wondering what the best practice is to do this while not creating complications if later merging a new release of the master plugin, which is at 3.2 right now.
Since one goal is to avoid uninstalling (and hence reinstalling), your part c seems unnecessary, unless you plan to deploy the fork in a new, different installation. Even though we usually don’t use that many points, 3.2.0.1 might be the way to go so that when you merge new updates from master, those will trigger the upgrade from our end.
Speaking of the merges, that might be tricky to manage due to the possible conflict of hookUpgrades from master and your fork, but it should be okay with some care. If your git-fu is strong, in similar situations I’ve worked from a local repo with two different remotes – one for the master and one for my fork. That way when merging git guides me to the conflicts that I need to resolve. Not sure if that counts as a best practice, but it’s worked in the past.
Of course, if this is a one-off thing, there’s the brute-force approach of just directly editing the table through something like PHPMyAdmin.
I suspect others might have other perspectives, too.