Rename artifact from opensearch-1.0.0-linux.x64.tar.gz to something else

[dblock]

Is your feature request related to a problem? Please describe.

We are naming the bundle that contains OpenSearch and plugins as opensearch-1.0.0-beta1-linux.x64.tar.gz, which is the same name as what is produced out of this repository. Let's find a new name, maybe -min? This artifact would be equivalent to elasticsearch-oss and would be released along with OpenSearch.

Describe the solution you'd like

A different name for the artifacts coming out of this repository.

Describe alternatives you've considered

We considered naming OpenSearch+plugins a bundle, but decided that for users we want a single downloadable OpenSearch product that contains everything they want to run, so we wanted that to be called "opensearch".

Additional context

https://discuss.opendistrocommunity.dev/t/naming-for-opensearch-1-0-distributions/5789

opensearch-project/OpenSearch-Dashboards#319

[dblock]

An alternative would be to get rid of https://github.com/opensearch-project/OpenSearch/blob/main/buildSrc/src/main/java/org/opensearch/gradle/DistributionDownloadPlugin.java altogether and never have to release a .tar.gz.

[nknize]

Getting rid of DistributionDownloader will break backward compatibility tests.

I'm good w/ renaming the .tgz build artifact here if it will clash w/ the published OpenSearch download page. I do think third party plugins need a path to develop w/ "experimental" or nightly builds. So if we could host a public facing maven repo where we publish nightly artifacts, third party plugins could update their build.gradle w/ opensearch_version = System.getProperty("opensearch.version", "1.0.0-SNAPSHOT-NIGHTLY####")

And add a repositories.gradle file like:

repositories {
    maven {
        url 's3://OPENSEARCH_MAVEN_REPO'
    }
    mavenCentral()
    jcenter()
}

Couple this with a sandbox module and I think we have a winner to lower the bar for the community to quickly churn on developing experimental features!

[rursprung]

the last status i saw was the discussion on the forum about whether opendistro plugins should be bundled with opensearch it was still open. has there now been a decision on this? sorry, i hadn't replied there anymore, i've added a comment now.

do i understand it correctly that you now want to ship a packaged labelled opensearch which contains opensearch + the opendistro plugins (i know, opendistro as a name is being dropped, but for now it makes talking about it easier 🙂) and one which only contains opensearch which you now want to call something like opensearch-min?

is this a done decision? or should the discussion be continued here or in the forum thread (the one i linked or the one you linked?)?

[dblock]

the last status i saw was the discussion on the forum about whether opendistro plugins should be bundled with opensearch it was still open. has there now been a decision on this? sorry, i hadn't replied there anymore, i've added a comment now.

This is the current thinking. I am afraid to call this "a decision" because we can still change our mind if we choose to for good reason.

do i understand it correctly that you now want to ship a packaged labelled opensearch which contains opensearch + the opendistro plugins (i know, opendistro as a name is being dropped, but for now it makes talking about it easier 🙂)

We can start calling "opendistro plugins", "OpenSearch plugins". These have been forked and are being worked on in opensearch-product. We'll leave opendistro alone to avoid confusion :) So yes, we want a package (a .tar.gz) that will ship a bundle of OpenSearch engine and OpenSearch plugins.

and one which only contains opensearch which you now want to call something like opensearch-min?

Nope. No package. But the .jars would be available in Maven under the -min name.

is this a done decision? or should the discussion be continued here or in the forum thread (the one i linked or the one you linked?)?

Let's not call it a done done, because if there's a good reason not to do it, then we should talk about it. The forum is the right place for non-technical/strategic discussions, please do contribute there, much appreciated. This item is assuming we are going with this plan.

[geekygirldawn]

@dblock:

The forum is the right place for non-technical/strategic discussions, please do contribute there, much appreciated. This item is assuming we are going with this plan.

I expect some of us are struggling a bit with the split between how the folks at AWS see conversations in the forum vs. GitHub. None of the other open source projects that I work on use forums for discussions about strategic topics related to the future of the project, but some do use them for end user support questions about using the technologies. Kubernetes, for example uses GitHub issues for exactly these types of strategic discussions. I'm not necessarily saying that we need to change anything, but I wanted to highlight this as something that is likely to continue to make things more difficult for a lot of your contributors.

[dblock]

@dblock:

The forum is the right place for non-technical/strategic discussions, please do contribute there, much appreciated. This item is assuming we are going with this plan.

I expect some of us are struggling a bit with the split between how the folks at AWS see conversations in the forum vs. GitHub.

I have the same problem. This is @stockholmux's domain, cc-ed.

[dblock]

I'm closing this in favor of a separate issue to release a standalone artifact equivalent to elasticsearch-oss.