# X-pack plugin version hell \[feature request?\]

**URL:** <https://discuss.elastic.co/t/x-pack-plugin-version-hell-feature-request/118238>\
**Category:** Elasticsearch\
**Created:** [February 2, 2018, 2:19pm UTC](https://discuss.elastic.co/t/x-pack-plugin-version-hell-feature-request/118238 "2018-02-02T14:19:25Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Guy\_Wicks](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/guy_wicks/32/5278_2.png) [@Guy\_Wicks](https://discuss.elastic.co/u/Guy_Wicks)\
**Post date:** [February 2, 2018, 2:19pm UTC](https://discuss.elastic.co/t/x-pack-plugin-version-hell-feature-request/118238/1 "2018-02-02T14:19:25Z")

</div>

Something that STOPS me from using the otherwise very useful x-pack on my cluster is that I have to exactly match the ES and x-pack version numbers. I've been in situations where my ES server has patched, upgraded and then failed to restart - due the the ES x-pack plug in now being out of date.

Would it be possible to have the x-pack plug in ALSO available in the RPM repository so that it can be kept in step with ES and Kibana?

Or - can the x-pack plug in have a more relaxed tolerance for matching version numbers - something that ES and Kibana has thankfully put in place.

Or - can the ES rpm have a 'disable any old plug-ins' feature (and associated warning) as it upgrades

Or - can the ES rpm FAIL TO INSTALL if there are plug-ins that will be incompatible

One of these options has to be better than the current situation (or I just don't use otherwise useful plug-ins)

Thanks in advance.

---

<div class="post-metadata">

**Author:** ![rjernst](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rjernst/32/6363_2.png) [@rjernst](https://discuss.elastic.co/u/rjernst)\
**Post date:** [February 9, 2018, 6:28pm UTC](https://discuss.elastic.co/t/x-pack-plugin-version-hell-feature-request/118238/2 "2018-02-09T18:28:39Z")

</div>

You need to make removing and re-installing plugins part of your upgrade process. This is not specific to x-pack: it is relevant for all plugins, regardless of whether they are developed by elastic or otherwise.

---

<div class="post-metadata">

**Author:** ![Guy\_Wicks](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/guy_wicks/32/5278_2.png) [@Guy\_Wicks](https://discuss.elastic.co/u/Guy_Wicks)\
**Post date:** [February 13, 2018, 8:06am UTC](https://discuss.elastic.co/t/x-pack-plugin-version-hell-feature-request/118238/3 "2018-02-13T08:06:49Z")

</div>

That didn't really answer the question(s), it rather just dimissess it ! I'm trying to reduce the admin overhead time on my installation, and suggest ways that you could support this for your users.

The x-beats plugin is totally under your control, and it is something that you encourage implementers to use.

It was of some interest that you DO package up x-beats with your Docker deployment.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [March 13, 2018, 8:06am UTC](https://discuss.elastic.co/t/x-pack-plugin-version-hell-feature-request/118238/4 "2018-03-13T08:06:52Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.