I think the ES cutover should be the start of the 0.5.x series, and we continue on with 0.4.x for the metadata improvements etc. We could chose to focus 0.5.x’s first releases on not only ES but getting a handle on kibana and the mpack situation as well.
On November 6, 2017 at 12:48:45, Michael Miklavcic ( michael.miklav...@gmail.com) wrote: I agree with your proposal, Nick. I think having a stabilizing release prior to upgrading ES/Kibana makes sense. On Mon, Nov 6, 2017 at 9:16 AM, Nick Allen <n...@nickallen.org> wrote: > I would like to start a discussion around upcoming releases. We have a > couple separate significant tracks of work that we need to reconcile in our > release schedule. > > (1) We have had (and have in review) a good number of bug fixes required to > support Metaalerts on the existing Elasticsearch 2.x infrastructure. > > > (2) We also have ongoing work to upgrade our infrastructure to > Elasticsearch 5.x, which will not be backwards compatible. > > > I would like to see a release that has our best work on ES 2.x before we > migrate to 5.x. I would propose the following. > > Release N+1: Introduce Metaalerts running on ES 2.x > > Release N+2: Cut-over to ES 5.x > > > (Q) Is it worth cutting a separate release for ES 2.x? Is there a better > way to handle the cut-over to 5.x? >
