Describe the feature: Docker images should be available with major and minor version tags
Rationale:
There are CI use cases where we're not running a cluster, but just want to make sure our integration works with the supported version of Elasticsearch, e.g. 6.x
Follow up from https://github.com/elastic/elasticsearch-docker/issues/84#issuecomment-490204354
Yes, it's been explained that it's not safe for deployment use: https://github.com/elastic/elasticsearch-docker/issues/84#issuecomment-358976967
But it's important for CI. For example, we're forced to manually pin a version now, when in fact we need to make sure that our integration works with the latest version of Elasticsearch 6.x: https://github.com/api-platform/core/blob/v2.4.5/.circleci/config.yml#L204
Pinging @elastic/es-core-infra
@teohhanhui As you mention, this suggestion has been brought up before in several issues. In addition to the one you linked, there is also https://github.com/elastic/elasticsearch-docker/issues/75. While we understand the desire, we believe production should be tied to a specific version of Elasticsearch due to the many concerns in how upgrades must be handled. Transitively, any testing of a product against Elasticsearch should likewise test a specific version since that version would then presumably be deployed to production.
Give that our stance has not changed, I hope you don't mind that I close this issue.
@rjernst That argument makes no sense. We're talking about a library that supports Elasticsearch as a data source. Why would we want to test with a specific version? We want to test with the latest version of a major branch, to ensure new changes don't break the integration.
Pinning to a specific version makes sense for a product, not for a library.
I'd like to point that debian packages ARE available by major version :)
-> deb https://artifacts.elastic.co/packages/7.x/apt stable main
That's a bit weirdo to not support major versions as well with docker...