2021 Ericsson AB. All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Upcoming Potential Incompatibilities

upcoming_incompatibilities.xml

## Introduction

This document lists planned upcoming potential incompatibilities in Erlang/OTP.

## OTP 25

### Distribution flags will become mandatory

In OTP 25, more distribution flags will become mandatory. That is, Erlang nodes will refuse to connect to nodes not implementing all of the mandatory distribution flags. If you implement the Erlang distribution protocol yourself, you will need to implement support for all mandatory distribution flags in order to communicate with Erlang nodes running OTP 25.

The following distribution flags will become mandatory in OTP 25:

DFLAG_BIT_BINARIES Support for bitstrings. DFLAG_EXPORT_PTR_TAG Support for external funs (fun Module:Name/Arity). DFLAG_MAP_TAGS Support for maps. DFLAG_NEW_FLOATS Support for the new encoding of floats. DFLAG_FUN_TAGS Support for funs, but only in the new format (NEW_FUN_EXT) because DFLAG_NEW_FUN_TAGS is also mandatory.

## OTP 26

### The distribution flag DFLAG_V4_NC will become mandatory

As of OTP 26, the distribution flag DFLAG_V4_NC will become mandatory. If you implement the Erlang distribution protocol yourself, you will need to implement support for DFLAG_V4_NC in order to communicate with Erlang nodes running OTP 26.

### The new link protocol will become mandatory

As of OTP 26, the new link protocol will become mandatory. That is, Erlang nodes will then refuse to connect to nodes not implementing the new link protocol. If you implement the Erlang distribution yourself, you are, however, encouraged to implement the new link protocol as soon as possible since the old protocol can cause links to enter an inconsistent state.

### Atoms will be encoded as UTF-8 by default

As of OTP 26, the functions erlang:term_to_binary/1,2 and erlang:term_to_iovec/1,2 will encode all atoms as UTF-8 by default. The current default behavior is to encode atoms as Latin-1 if possible.

If you implement your own decoding of the Erlang external format you must either:

Make sure your implementation supports the UTF-8 encodings ATOM_UTF8_EXT and SMALL_ATOM_UTF8_EXT.

Call erlang:term_to_binary/2 or erlang:term_to_iovec/2 with option {minor_version,1} to force Latin-1 encoding. This is a more short-term solution as Latin-1 encoding may be phased out and removed in later OTP releases.