I agree, I think it's very reasonable to move in line with Nick's proposal. I would also suggest that we outline what the target versions would be to add in the METRON-777 components, since it has been functional for a very long time but not reviewed and has some really rockstar improvements.
Jon On Mon, Nov 6, 2017 at 12:56 PM Otto Fowler <ottobackwa...@gmail.com> wrote: > 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? > > > -- Jon
