I have noticed this problem come up a few times here.
Often the solution is “update your version of Discourse, update your version of the plugin”
This works fine as long as one is able and willing to update, But there are times when that is not an option, eg. when the version of Discourse is Stable.
I have always worked on localhost with the current latest version so I might have missed something, but I’m wondering if there is an easy way to “tie” a plugin version to a particular Discourse version.
Perhaps the plugin API number can already do this?
If not, maybe a type of “#compatibility” or “#requires” comment could be added to the plugin.rb file that if not used by code could at least be found when problems arise because of version conflicts?
I’ll put this here again, as I’ve talked about it deep down into another topic
In short, I tag my repo with a version number (associated to the plugin). So let’s say Core breaks my plugin, I’ll tag the current state of my plugin as a specific version and then start the development of the next version that works with latest.
This permits those on older versions of Discourse to still use my plugin, they just have to alter their app.yml to reference the tag/branch. And those that run latest, can pull down latest without any issue as well.
It has worked well for the subset of plugins I maintain. It took me a while to get in the habit of doing those steps, and I know a few of the plugins I built have had people make use of the tag/branch until they could upgrade their Discourse instance accordingly.
In other words, a tag is like a “pointer” to particular place in the sequence of commits.
Any “notes” regarding compatibility can be put into the readme / plugin.rb file prior to tagging.
Technically, yes, it is just the syntax you use to clone a branch versus a tag are the same.
Correct. It doesn’t have to be numbers at all. You could tie it to Discourse version numbers if you wanted as well (I have yet to do that – though I feel it would be one day a smart thing to do).