Bump to version 8.7.0

.backportrc.json

@@ -1,9 +1,9 @@
 {
   "upstream" : "elastic/elasticsearch",
-  "targetBranchChoices" : [ "main", "8.5", "8.4", "8.3", "8.2", "8.1", "8.0", "7.17", "6.8" ],
+  "targetBranchChoices" : [ "main", "8.6", "8.5", "8.4", "8.3", "8.2", "8.1", "8.0", "7.17", "6.8" ],
   "targetPRLabels" : [ "backport" ],
   "branchLabelMapping" : {
-    "^v8.6.0$" : "main",
+    "^v8.7.0$" : "main",
     "^v(\\d+).(\\d+).\\d+(?:-(?:alpha|beta|rc)\\d+)?$" : "$1.$2"
   }
 }

.ci/bwcVersions

@@ -79,3 +79,4 @@ BWC_VERSION:
   - "8.5.1"
   - "8.5.2"
   - "8.6.0"
+  - "8.7.0"

.ci/snapshotBwcVersions

@@ -2,3 +2,4 @@ BWC_VERSION:
   - "7.17.8"
   - "8.5.2"
   - "8.6.0"
+  - "8.7.0"

build-tools-internal/version.properties

@@ -1,4 +1,4 @@
-elasticsearch     = 8.6.0
+elasticsearch     = 8.7.0
 lucene            = 9.4.1
 
 bundled_jdk_vendor = openjdk

docs/reference/migration/index.asciidoc

@@ -1,6 +1,6 @@
 include::migration_intro.asciidoc[]
 
-* <<migrating-8.6,Migrating to 8.6>>
+* <<migrating-8.7,Migrating to 8.7>>
 * <<migrating-8.5,Migrating to 8.5>>
 * <<migrating-8.4,Migrating to 8.4>>
 * <<migrating-8.3,Migrating to 8.3>>
@@ -8,7 +8,7 @@ include::migration_intro.asciidoc[]
 * <<migrating-8.1,Migrating to 8.1>>
 * <<migrating-8.0,Migrating to 8.0>>
 
-include::migrate_8_6.asciidoc[]
+include::migrate_8_7.asciidoc[]
 include::migrate_8_5.asciidoc[]
 include::migrate_8_4.asciidoc[]
 include::migrate_8_3.asciidoc[]

docs/reference/migration/migrate_8_7.asciidoc

@@ -0,0 +1,22 @@
+[[migrating-8.7]]
+== Migrating to 8.7
+++++
+<titleabbrev>8.7</titleabbrev>
+++++
+
+This section discusses the changes that you need to be aware of when migrating
+your application to {es} 8.7.
+
+See also <<release-highlights>> and <<es-release-notes>>.
+
+coming::[8.7.0]
+
+
+[discrete]
+[[breaking-changes-8.7]]
+=== Breaking changes
+
+// tag::notable-breaking-changes[]
+There are no breaking changes in {es} 8.7.
+// end::notable-breaking-changes[]
+

docs/reference/release-notes.asciidoc

@@ -6,7 +6,7 @@
 
 This section summarizes the changes in each release.
 
-* <<release-notes-8.6.0>>
+* <<release-notes-8.7.0>>
 * <<release-notes-8.5.1>>
 * <<release-notes-8.5.0>>
 * <<release-notes-8.4.3>>
@@ -35,7 +35,7 @@ This section summarizes the changes in each release.
 
 --
 
-include::release-notes/8.6.0.asciidoc[]
+include::release-notes/8.7.0.asciidoc[]
 include::release-notes/8.5.1.asciidoc[]
 include::release-notes/8.5.0.asciidoc[]
 include::release-notes/8.4.3.asciidoc[]

docs/reference/release-notes/8.7.0.asciidoc

@@ -0,0 +1,8 @@
+[[release-notes-8.7.0]]
+== {es} version 8.7.0
+
+coming[8.7.0]
+
+Also see <<breaking-changes-8.7,Breaking changes in 8.7>>.
+
+

docs/reference/release-notes/highlights.asciidoc

@@ -12,97 +12,21 @@ endif::[]
 // Add previous release to the list
 Other versions:
 
-{ref-bare}/8.4/release-highlights.html[8.4]
+{ref-bare}/8.6/release-highlights.html[8.6]
+| {ref-bare}/8.5/release-highlights.html[8.5]
+| {ref-bare}/8.4/release-highlights.html[8.4]
 | {ref-bare}/8.3/release-highlights.html[8.3]
 | {ref-bare}/8.2/release-highlights.html[8.2]
 | {ref-bare}/8.1/release-highlights.html[8.1]
 | {ref-bare}/8.0/release-highlights.html[8.0]
 
+// The notable-highlights tag marks entries that
+// should be featured in the Stack Installation and Upgrade Guide:
 // tag::notable-highlights[]
-
+// [discrete]
-[discrete]
+// === Heading
-[[speed_up_sql_queries_by_not_tracking_total_hits_by_default]]
+//
-=== Speed up SQL queries by not tracking total hits by default
+// Description.
-SQL query translator now explicitly sets track_total_hits to false when
-not needed.
-This has a significant impact on SQL query performance in cases where total hits
-are not needed to calculate the final result, in particular when the cost of evaluation
-of a single document is particularly high (eg. queries that involve script evaluation)
-and in queries with a small LIMIT value.
-In our tests, on some specific queries, we see a speed-up of more than 50%,
-with peaks of ~95% (from 600ms to 20ms).
-
-{es-pull}89106[#89106]
-
-[discrete]
-[[ilm_no_longer_rolls_over_empty_indices]]
-=== ILM no longer rolls over empty indices
-For both new and existing Index Lifecycle Management (ILM) policies,
-the rollover action will only execute if an index has at least one document.
-
-
-For indices with a `max_age` condition that are no longer being written
-to, this will mean that they will no longer roll over every time their
-`max_age` is reached.
-
-A policy can override this behavior, and explicitly opt in to rolling over
-empty indices, by adding a `"min_docs": 0` condition:
-
-[source,console]
-----
-PUT _ilm/policy/allow_empty_rollover_policy
-{
-  "policy": {
-    "phases": {
-      "hot": {
-        "actions": {
-          "rollover" : {
-            "max_age": "7d",
-            "max_size": "100gb",
-            "min_docs": 0
-          }
-        }
-      }
-    }
-  }
-}
-----
-
-This can also be disabled on a cluster-wide basis by setting
-`indices.lifecycle.rollover.only_if_has_documents` to `false`.
-
-{es-pull}89557[#89557]
-
-[discrete]
-[[release_time_series_data_stream_tsds_functionality]]
-=== Release time series data stream (TSDS) functionality
-Elasticsearch offers support for time series data stream (TSDS) indices.
-A TSDS index is an index that contains time series metrics data as part
-of a data stream. Elasticsearch routes the incoming documents into a TSDS
-index so that all the documents for a particular time series are on the
-same shard, and then sorts the shard by time series and timestamp. This
-structure has a few advantages:
-
-1. Documents from the same time series are next to each other on the shard, and
-hence stored next to each other on the disk, so the operating system pages are
-much more homogeneous and compress better, yielding massive reduction in TCO.
-
-2. The analysis of a time series typically involves comparing each two consecutive
-docs (samples), examining the last doc in a given time window, etc., which is quite
-complex when the next doc could be on any shard, and in fact on any index. Sorting
-by time series and timestamp allows improved analysis, both in terms of performance
-and in terms of our ability to add new aggregations.
-
-Finally,  as part of the Index Lifecycle Management of metrics data time series,
-Elasticsearch enables a Downsampling action. When an index is downsampled,
-Elasticsearch keeps a single document with statistical summaries per each bucket
-of time in the time series. Supported aggregations can then be run on the data
-stream and include both downsampled indices and raw data indices, without the
-user needing to be aware of that. Downsampling of downsampled indices, to more
-coarse time resolution, is also supported.
-
-{es-pull}90116[#90116]
-
 // end::notable-highlights[]
 
 

server/src/main/java/org/elasticsearch/Version.java

@@ -127,7 +127,8 @@ public class Version implements Comparable<Version>, ToXContentFragment {
     public static final Version V_8_5_1 = new Version(8_05_01_99, org.apache.lucene.util.Version.LUCENE_9_4_1);
     public static final Version V_8_5_2 = new Version(8_05_02_99, org.apache.lucene.util.Version.LUCENE_9_4_1);
     public static final Version V_8_6_0 = new Version(8_06_00_99, org.apache.lucene.util.Version.LUCENE_9_4_1);
-    public static final Version CURRENT = V_8_6_0;
+    public static final Version V_8_7_0 = new Version(8_07_00_99, org.apache.lucene.util.Version.LUCENE_9_4_1);
+    public static final Version CURRENT = V_8_7_0;
 
     private static final Map<Integer, Version> idToVersion;
     private static final Map<String, Version> stringToVersion;