Hello,
Just a quick question about how OpenSearch and OpenSearch-Dashboards versioning are managed. Will both products live an independant life in terms of versioning ? My question is related to the fact that anOpenSearch version 1.2.1 was released and not OSD (might be a simple question of delay though).
Thanks for your feedback.
Lionel
1.2.1 was released to fix the log4j issue which everyone has been talking about this past weekend. There was no need to release Opensearch Dashboards since it was not affected by that security issue.
I understand this point (and aware of CVE).
But my question was more related to the way to manage versions of both products.
Does that mean that both products OS + OSD will live an independent life ? (which is fine to me but just want to make sure).
Right now we build and test OpenSearch, OpenSearch Dashboards, and all the plugins for both together for every minor version release. E.g. everything 1.2.X is tested together.
For patch releases, where the third number increments (e.g. moves from 1.2.0 to 1.2.1) we only update the parts that have changed. So in this case, no code changes were introduced to OpenSearch Dashboards, so issuing a new release for it would have meant releasing software where the only change is an incremented version number.
I hope that helps. One follow-on action we took from this weekend’s work is to add details about these questions to the FAQs, so look for that coming soon.
Thanks a lot for the clarifications. It helps (mainly for stack deployment automation in dev env).
What Jules said.
To expand a bit, versioning is a surprisingly interesting topic in a distribution like this. One of the biggest differences between the ELK stack and OpenSearch is how versioning is approached and the project is still working out the corner cases. There is a lot of thought going on to make it crystal clear to users what version of the distribution they are on. In the past it’s also been muddy in other ways (e.g. OpenSearch 1.0.1 was a plug-in only update, so there wasn’t a great way in the API or Dashboards to tell if you’ve updated, aside from looking the plugin versions). That being said, feedback is appreciated.
In our specific case, we developed a script to deploy ELK or Opensearch distributions based on a version number: e.g. ELK 7.9.2. Based on that version, a docker-compose file is created to deploy Kibana or OSD and Elastic or OS containers with the same version number.
I cannot think (but might be wrong) of a release made by Elastic at least from 6.8.1 with “only” a security update.
Coming back to versioning, I think we all agree it’s a waste of time releasing a product without any changes but the version number somewhere in a file. However, if going this way, we will need to have a stack version or compatibility matrix or whatever we want to call it. In my case, I am going to setup a stack version number to handle patch versions in releases (not a big deal).
Yeah, OpenSearch adheres to SemVer quite tightly. Patches versions are patches - no new features in patches, only fixes. So, software that doesn’t change doesn’t increment. The distribution is an amalgamation of a bunch of software, so if one thing changes, the whole thing gets incremented and that needs to be surfaced. There are a few open issues and PRs that address this with the manifest files that probably fill your need for a matrix.
In the mean time, there is also the “version” files of the website that actually codify this information (plus some extra stuff) at a high level too. See the components section of of the 1.2.1 version file as an example.