here’s a vote in favour of having another 1.x release:
there are two features for the security plugin which we need which are not yet in 1.3 (one has been merged to master a few days ago, the other one is still lacking a PR which will however hopefully come soon). having them in 2.x means that we’d have to do an upgrade from elasticsearch 7.10.2 to opensearch 2.x which contains breaking changes, so we might also run into issues with 3rd party libraries and products (not all support opensearch yet, e.g. spring-data-elasticsearch).
having a 1.4 release containing these features would give us a way to already migrate from elasticsearch 7.10.2 to opensearch as a first (and important) step. from there we can then properly plan the upgrade with breaking changes (which is a bit more complicated for us, as outlined in this thread).
this is, admittedly, a very selfish view as others might not depend on these features… so here’s a more general view:
the more general problem with a 2.x release (i.e. a release with breaking changes) now is that there are still gaps when it comes to clients (esp. e.g. the mentioned spring-data-elasticsearch) and until this is resolved it’s not possible to move to a 2.x release for users of such libraries. and during that time it should be possible to still have 1.x releases to have a clear upgrade path and important new features.
maybe it’d make sense to gather a list of gaps (missing features) which currently prevent people from migrating to opensearch and ensure that they are filled before abandoning the “stepping stone” 1.x release? this will include some features in opensearch (or, more likely, opensearch plugins) and some client work, maybe also some things around (think e.g. the kubernetes operator as some might currently be using ECK and waiting for that to migrate over).
specifically e.g. for spring-data-elasticsearch they plan to only add proper opensearch support in a new major version: Prepare for the "next generation" clients · Issue #1853 · spring-projects/spring-data-elasticsearch · GitHub
so that means that users of this library can use it for now (in a slightly outdated version which uses a RestHighLevelClient w/o the version/license check) with ES 7.10.2 and opensearch 1.x but will then have to first upgrade (and roll out) their client applications to use the new major release of spring-data-elasticsearch before they can start upgrading their cluster(s). this already creates a dependency chain which has to be managed.
also, some people might not yet be able to migrate because their distribution is not yet supported, this board seems to give an overview: OpenSearch distributions · GitHub