Hello,
The problem I'm describing is rather predictable/obvious, but quite frustrating.
The release cycle for Kibana is very fast and the plugins that worked fine for Kibana 5.0.0 break (to be precise: get turned off because of version discrepancy) after an upgrade to 5.0.1, even though it seems that such small upgrade (bugfixes mostly) shouldn't break them.
Is there any way to prevent this except for waiting for plugin updates or sticking with an older version of Kibana?
Maybe it would make sense to allow using 5.0.0 plugins with all 5.0.x versions and let the user decide if they work as expected?
I would even go as far to say, 5.x.x there should be no breaking changes between minor releases either. Or how about the way node does it say ">5.0.1" so the plugin says it needs "Greater then Version 5.0.0
Do as follows:
a) download your plugin,
b) unzip it into $KIBANA_HOME/plugins,
c) change "version" in the package.json file to match your Kibana version, e.g.: "version": "5.0.1"
This requires changing after each update.
Do as in 1, but change "version" to "kibana" ("version": "kibana"), the same way it is set up in core plugins ($KIBANA_HOME/src/core_plugins), as proposed by one of the plugin developers: https://github.com/JuanCarniglia/area3d_vis/issues/1 - it seems that whis will work for all further updates, but is less safe.
Yah I was reading that chain of conversation. I don't like the tone of it, basically from reading the conversation Elastic developers are saying tough we want tight validation of the plugins so they don't have to have to worry about backwards compatibility.
I am sorry but at the pace Elastic is moving you have to start guaranteeing some kind of compatibility between point releases. You can't keep making breaking changes all the time.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.