Plugin version constraints

[michaelklishin]

All plugins only support so many RabbitMQ server versions, often a single series, e.g. 3.6.x. Currently there is no mechanism for RabbitMQ broker to check if a plugin is compatible or not, which leads to obscure issues when incompatible plugins are deployed, enabled, and then used.

We should introduce a mechanism for plugin authors (including our own team) to indicate what versions a plugin is compatible with. Incompatible plugins must be logged and ignored.

[michaelklishin]

@gotthardp @gmr would love to hear your thoughts on this.

[hairyhum]

Since plugins are erlang applications, the most obvious idea is to use application versions and format them in some way. But it can be not enough to determine obsolete plugins.

[michaelklishin]

We cannot determine if a plugin is compatible. We should give plugin authors the tools to explicitly say what version range(s) they support, then filter out those that do not match.

[hairyhum]

Then we can rely on application version. If it is formatted to some expression, that broker can parse. Maybe not the best idea, because it can violate some standards of application versioning.

[hairyhum]

It's possible to define custom application key in .app.src with something like {rabbitmq_versions, ["3.5.6", "3.6.0"]} wth minimal minor version for each major (major is "3.6"). And then check using rabbit_misc:version_minor_equivalent and rabbit_misc:version_compare.
This approach is based on assumption that we will not break any plugins by changing minor version.

[gmr]

@hairyhum I think that's a good way to go.