root
/
elasticsearch
mirror of https://github.com/elastic/elasticsearch.git
1
0
Fork 0
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Bump to version 8.7.0

This commit is contained in:
Iraklis Psaroudakis 2022-11-16 16:32:19 +02:00
parent 787aca8a69
commit a3b06e1d68
10 changed files with 50 additions and 93 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.backportrc.json
View File

@ -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"
}
}

1
.ci/bwcVersions
View File

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

1
.ci/snapshotBwcVersions
View File

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

2
build-tools-internal/version.properties
View File

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

4
docs/reference/migration/index.asciidoc
View File

@ -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[]

22
docs/reference/migration/migrate_8_7.asciidoc Normal file
View File

@ -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[]

4
docs/reference/release-notes.asciidoc
View File

@ -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[]

8
docs/reference/release-notes/8.7.0.asciidoc Normal file
View File

@ -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>>.

94
docs/reference/release-notes/highlights.asciidoc
View File

@ -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]
[[speed_up_sql_queries_by_not_tracking_total_hits_by_default]]
=== Speed up SQL queries by not tracking total hits by default
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]
// [discrete]
// === Heading
//
// Description.
// end::notable-highlights[]

3
server/src/main/java/org/elasticsearch/Version.java
View File

@ -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;