Request of new track for the OpenSearch snap

Hi, I would like to request the creation of a new track 2/ for the opensearch snap - in order to stay aligned with the upstream version of opensearch. Thank you


Per Process for aliases, auto-connections and tracks 2, we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.

I have three questions before casting my vote.

  1. What’s opensearch’s release cadence, how often is a new major version (potentially requiring a new track) released? is this documented somewhere by upstream?
  2. Is there some commitment from upstream on maintenance of old versions? e.g. is 1.x still supported with security updates? will it continue to be supported now that 2.x is out, and for how long?
  3. Are new versions backwards-incompatible? meaning, if I was running 1.x and try to install 2.0, will that just work, or do I need to migrate my data/configuration, or will things break horribly?


  • Daniel


Thanks for your response!

  1. It is unclear when will the 3.0 be released, but as per the 1.0 and 2.0 releases, I would say it’s safe to assume that the cadence for a major release is ~1y (for minor versions i.e 2.5.0 -> 2.6.0 is around 1 - 2 months)
  2. Such a commitment exists for both latest major version + latest major version -1 (taking into consideration roughly a 1y major version release cadence - that makes the support of each major version lasts 2y or slightly more). From the official website:

The duration of the maintenance window will vary from product to product and release to release. By default, versions will remain under maintenance until the next major version enters maintenance, or 1 year passes, whichever is longer. Therefore, at any given time, the current major version and previous major version will both be supported, as well as older major versions that have been in maintenance for less than 12 months.

  1. A major version may introduce breaking changes, new APIs, deprecated APIs and tooling BUT upstream usually commits to provide the necessary tooling / guides to perform such migration.

Thank you! Mehdi

Hey there,

Since manual process is required to perform an upgrade, it sounds to me like it’s a good use case for tracks.

+1 as reviewer, the track is created.

  • Daniel
1 Like