Update to support current OTP and rebar3

[avtobiff]

There are a few issues open on supporting more
recent OTP releases than OTP 24 and also requests
to support more recent rebar3 releases.

basho/riak_kv#1884
basho/riak#1136
basho/riak#1133

I tried compiling with otp HEAD and rebar3 HEAD
and got the following laundry list of fixes in
components necessary to build riak.

Should perhaps some of these components use the
canonical upstream repositories where some of these
issues might already be fixed?

Should fixes for riak components pull request towards
openriak repositories?

Fixes necessary to build riak with current otp and rebar3

gpb

• 4.13.0 -> 4.21.1

leveled

• leveled_log: move include to after exports
• format_status/2 -> format_status/1

kv_index_tictactree

• gen_fsm -> gen_statem

mochiweb

• mochiweb_multipart: quote the 'maybe' atom

riakc

• riakc_datatype: -type maybe -> maybe_t

riak_ensemble

• riak_ensemble_client: quote the 'maybe' atom
• riak_ensemble_peer: gen_fsm -> gen_statem

poolboy

• gen_fsm -> gen_statem
• upstream replaced gen_fsm with gen_server

clique

• clique_table -> %% ?else

riak_core

• riak_core_worker_pool: gen_fsm -> gen_statem
• riak_core_coverage_fsm: gen_fsm -> gen_statem
• riak_core_vnode: gen_fsm -> gen_statem
• riak_core_tracer: dbg:stop_clear/0 -> dbg:stop/0

riak_pipe

• riak_pipe_vnode_worker: gen_fsm -> gen_statem
• riak_pipe_builder: gen_fsm -> gen_statem
• riak_pipe_fitting: gen_fsm -> gen_statem

riak_api

• riak_api_pb_server: gen_fsm -> gen_statem

riak_kv

• riak_kv_queue_manager: format_status/2 -> format_status/1
• tracer_merge_and_and_handoff: dbg:stop_clear/0 -> dbg:stop/0
• tracer_eleveldb_put_size: dbg:stop_clear/0 -> dbg:stop/0
• tracer_fsm_init: dbg:stop_clear/0 -> dbg:stop/0
• riak_kv_yessir_backend: -type index_spec Index = SecondaryKey :: term()
• riak_kv_memory_backend: -type index_spec Index = SecondaryKey :: term()
• riak_kv_bitcask_backend: -type index_spec Index = SecondaryKey :: term()
• tracer_latency_histogram: dbp:stop_clear/0 -> dbg:stop/0
• riak_kv_eleveldb_backend: -type index_spec Index = SecondaryKey :: term()
• riak_kv_multi_prefix_backend: -type index_spec Index = SecondaryKey :: term()
• riak_kv_leveleb_backend: -type index_spec Index = SecondaryKey :: term()
• tracer_accumulating_time: dbg:stop_clear/0 -> dbg:stop/0
• riak_kv_replrtq_src: format_status/2 -> format_status/1
• riak_kv_mrc_sink: gen_fsm -> gen_statem
• riak_kv_multi_backend: -type index_spec Index = SecondaryKey :: term()
• riak_kv_exchange_fsm: gen_fsm -> gen_statem
• tracer_func_args: dbg:stop_clear/0 -> dbg:stop/0
• tracer_timeit: dbg:stop_clear/0 -> dbg:stop/0
• tracer_backend_latency: dbg:stop_clear/0 -> dbg:stop/0
• tracer_gc_latency: dbg:stop_clear/0 -> dbg:stop/0
• riak_kv_get_fsm: gen_fsm -> gen_statem
• riak_kv_2i_aae: gen_fsm -> gen_statem, format_status/2 -> format_status/1
• riak_kv_put_fsm: gen_fsm -> gen_statem

riak_repl:

• riak_core_service_conn: gen_fsm -> gen_statem
• riak_core_connection: gen_fsm -> gen_statem
• riak_core_cluster_conn: gen_fsm -> gen_statem
• riak_repl_keylist_client: gen_fsm -> gen_statem
• riak_repl_aae_source: gen_fsm -> gen_statem
• riak_repl_keylist_server: gen_fsm -> gen_statem

[martinsumner]

The openriak-3.4 branch is where the next release is being developed. The intention is that this should compile (without errors) on OTP 26. The majority of the issues you've discovered (with the exception of the gen_fsm/gen_statum ones) should be fixed on this branch.

For openriak-3.4, it will always pull from a local OpenRiak fork for each repository. However, all those forks have been taken from an up-to-date main branch.

The default openriak-3.2 branch is only targeted at a maximum of OTP 24, and that won't change. It will be replaced by the openriak-3.4 branch as the primary branch in due course - but the timeline won't be short as only a minority of Riak users have so far upgrade to 3.2.

[martinsumner]

Also see https://github.com/orgs/OpenRiak/discussions/1.

[martinsumner]

For openriak-3.4, that now passes all our tests. There's some further non-functional tests to be run, and there's some potential new features https://github.com/orgs/OpenRiak/discussions in the pipeline to be added before we make that an actual release.

For OTP versions beyond OTP 26, this will happen, but isn't prioritised at the moment as pre-testing OTP 27 revealed some significant performance issues. It will take time for people to migrate to 3.4, so we have time for the Erlang team to investigate this further.

[avtobiff]

Sweet!

Thanks for the swift response.