Description
Version numbers are user-facing: they appear in various log and exception messages that explain to the user why the action they are trying to take is invalid given the version(s) of Elasticsearch nodes observed in a cluster.
We have recently separated out the user-meaningful Version
constants into several independent version sequences in order to track the different aspects of compatibility to better support continuous delivery. Each different kind of version now renders as a simple integer, because the major.minor.patch
structure does not make sense under continuous delivery.
The trouble is that these integers are meaningless to users in a traditional (discontinuous?) delivery environment, and this is rather harmful to supportability. Previously users would see some message indicating that say 8.10.3
was incompatible with what they were trying to do and they'd know they were in the middle of an upgrade and just needed to wait until the cluster was all on 8.10.4
, but now they see version numbers like 8520000
and have no realistic way to map that onto a particular release version without opening a support case.
Can we fix up the user-facing versions in released versions so they map back onto user-facing version numbers?
Relates ES-6958.