We’re obviously talking at cross-purposes here.
I want to be able to specify a gem version range in my plugin, as is legal, as subversion/point releases of gems should maintain backwards-compatibility and only introduce bugfixes.
Attempting to install a plugin which includes a (legal) gem version range fails and does not generate an explicit error message.
Without wanting to put words in your mouth, you appear to be saying this is not supported because you (by policy rather than a technical reason) use explicit gem versions in plugins, and so this should be detected during plugin development.
The following questions are rhetorical.
So - at what point is it made clear that plugins should only use explicit gem versions because of your (internal?) development methodology?
For example, it’s not in https://github.com/discourse/discourse/blob/master/docs/VAGRANT.md or in discourse/DEVELOPER-ADVANCED.md at master · discourse/discourse · GitHub, or following the links from discourse/CONTRIBUTING.md at master · discourse/discourse · GitHub to Discourse Development Contribution Guidelines and from there to Beginner's Guide to Creating Discourse Plugins Part 1: Creating a basic plugin this isn’t - as far as I can see - mentioned at any point.
Hence my question - why should this fail?
My take-away from this is that as a “beginning” plugin developer I must adapt my normal practices to match how you write Discourse, much in the same way Rails isn’t really Ruby. It appears the barrier for entry is higher than I had originally thought and so needs more work on my part to create a development environment (with all its moving parts) that matches as closely as possible those in use by others, rather than developing on a “production mirror” (which, for example, normally makes sure that any changes I make will be exactly reflected when deployed).