Does that mean that if a severe security bug gets discovered in x-pack for ES 5.6.4, there’s no way for them to deliver a fix to a 5.6.4 customer other than forcing them to update the whole Elastic stack?
Have you seen how slow are people upgrading their ES clusters? We have customers in 5.1.x, 5.3.x, and refused to deal with a dozen others on 2.x. And these guys do not plan to update their cluster anytime soon. Which I understand, because it’s a extremely difficult to upgrade an ES cluster without downtime.
I really think binding x-pack version tightly to each Elastic Stack release is a bad idea. ReadonlyREST won’t follow this path and all our customers using supported ES versions will be able to receive the latest plugin code.
Another reason we can’t follow the Elastic Stack versioning alone, is that we simply don’t have control on when/how often they’ll release.
About the frequent releases of ROR
I believe ROR is releasing coming out often is symptomatic that we’re working hard on the product. The more customers we onboard, the faster we go due to the great input from very knowledgeable customers like yourself.
Having said that, I recognise that upgrading to a new release implies engineering time on customer side, so we’ll will try to keep it down to max 1 per month. Unless major things need to be fixed.