Roadmap - Draft Schedule and Scope for OpenRiak 3.2, 3.4 & 3.6

[martinsumner]

The Riak roadmap highlights plans for the current and next two major Riak releases:

• OpenRiak 3.2
• OpenRiak 3.4
• OpenRiak 3.6

OpenRiak 3.2

OpenRiak 3.2 - Scope

OpenRiak KV 3.2.3 has now been released. There's not expected to be any feature development on the 3.2 path going forward, however there is an outstanding snag-list of minor changes that may lead to a 3.2.4 release:

• https://github.com/OpenRiak/riak_kv/issues/45
• https://github.com/OpenRiak/riak_kv/issues/52
• https://github.com/OpenRiak/riak_kv/issues/54
• https://github.com/OpenRiak/riak/issues/22
• https://github.com/OpenRiak/riak_kv/issues/58
• Fold objects by_sqn continues to fold after the Journal snapshot SQN martinsumner/leveled#465

OpenRiak 3.2 - Schedule

OpenRiak 3.2 will be maintained as the recommended (by the OpenRiak community) production release of Riak until the end of 2025.

OpenRiak 3.4

OpenRiak 3.4 - Scope

The 3.4 release is expected to be optimised for OTP26, but will also support OTP24 in the initial release to assist with transition.

There are planned to be some significant new features:

• Enhancements to allow existing secondary indexes to be queried in a more flexible and developer-friendly way.
• A change to make conditional PUTs (for Compare-And-Swap type updates) more predictable in the context of race conditions.
• More flexible configuration of logging to make it easier to divert or suppress certain types of logs (e.g. backend logs, or logs with recurring metric updates).
• Enhancements to improve observation and control of Tictac AAE.
• Publication, and perhaps integration, of some existing third party tools to help with coordination between Riak and other database services (e.g. OpenSearch replication and reconciliation, readable S3 backups).

A big part of the scope of the broader work related to 3.4 release will be an update and refresh to the documentation. For the 3.4 release it is hoped that the documentation can be simplified by focusing only on the features that are expected to be used in Riak going forward. As part of this, a number of features will go dark within Riak 3.4: the features will still be present, and tested as part of the release, however they will not feature as a primary part of the 3.4 documentation (but guidance will still be found in previous versions in the documentation).

The features that are currently expected to enter dark mode in Riak 3.4:

• Riak Ensemble
• write-once path
• eleveldb backend
• memory backend
• multi-backend
• map/reduce queries
• Riak data-types
• legacy secondary index API (replaced by new query API)
• legacy anti-entropy (replaced by tictacaae)
• legacy replication methods (replaced by nextgenrepl)
• Object-specific PUT/GET options (for those options that can instead by set as a bucket property)
• Last write wins (allow_mult will continue to be configurable)
• Delete modes (only keep to be recommended)

For these "dark-mode" features it will be expected that for the OpenRiak 3.6 release, one of the following will occur: relaunch; pareto-replacement or retirement (default).

Relaunch

A relaunch may occur if there exists feedback that a feature is critical to a use-case that cannot be adequately resolved through alternative means. The relaunch will require a reassessment of the existing tests to ensure that the community is in a position to support the feature for the long-term.

As part of the reassessment of the feature, the intention will be to ensure that any relaunched feature is fully-compatible with all other features to be maintained in OpenRiak going forward. An important long-term goal is to reduce the number of caveats associated with feature combinations. It is also important that any relaunched feature does not contradict the non-functional goals of high-availability and predictable performance in Riak - either by addressing issues of scale or applying appropriate constraints.

For example if Riak data types are to be relaunched, then they may be enhanced to allow for the setting of secondary indexes on CRDT maps, and addressing issues of scale; so that CRDT objects can be expected to behave as with other objects.

Pareto Replacement

Generally replacement will be preferred to relaunch, where as part of that replacement 80% of the value can be retained at 20% of the overhead.

For example, if Map/Reduce is used primarily for multi-get or filtered fetches of JSON paths in objects: a feature may be added to perform those specific tasks only in a more reliable and developer-friendly way. For Riak data-types, if most of the use is for small sets or counters associated with existing keys: limited Riak data-types may be included for use in object metadata only.

Retirement (default)

If a feature is retired, it will be removed from OpenRiak 3.6. It will continue to be supported in OpenRiak 3.4. The changes necessary to uplift OpenRiak 3.4 for OTP 27 or 28 are not expected to be significant - so the potential longevity of the 3.4 release, in terms of compatibility with supported operating systems and hardware, may be to the end of the decade.

The focus of the maintenance team is expected move to OpenRiak 3.6 towards the end of 2026, so getting help with issues in OpenRiak 3.4 beyond 2027 may depend on the Riak community and the paid-for support providers within it.

OpenRiak 3.4 - Schedule

OpenRiak 3.4 is currently under active development, but is available for pre-production testing, along with an updated functional test system. The following roadmap of events is expected:

• March 2025 - release of initial non-functional test results, and peer-review complete of major functional changes.
• May 2025 - tagging of initial release-candidate for formal testing.
• October 2025 - tagging of production-ready release, with renewed documentation and exemplar clients.
• 2026 - potential uplift of OpenRiak 3.4 to be made compatible with later OTP releases.

OpenRiak 3.6

The OpenRiak 3.6 release is expected to be optimised for OTP28, but will also support OTP26 in the initial release to assist with transition.

OpenRiak 3.6 - Scope

The scope of the OpenRiak 3.6 release will be determined by the feedback on the impact of features entering 'dark-mode' in OpenRiak 3.4. Currently it is expected that development will be focused on supporting the transition away from retired features and the resolution of internal technical debt. OpenRiak 3.6 will better utilise underlying BEAM capabilities where such capabilities can replace bespoke development. OpenRiak 3.6 will remove all legacy code relying on suppressed deprecation warnings - in particular the use of Erlang FSMs. It is also expected that large C/C++ dependencies (other than compression libraries) will be removed, improving build times and build portability.

OpenRiak 3.6 - Schedule

Work on providing an initial openriak-3.6 branch and resolving compatibility issues related to the OTP 28 update is expected to be complete by March 2026. A roadmap for release candidate and other release dates will be made available then.

[tburghart]

A Note on Protocol Compatibility

There are ongoing discussions around TLS everywhere, and such capability is likely to coincide with the 3.6 timeframe. It's also possible that the preferred implementation of consistently-configured TLS may dictate a change in how connection handshaking and authentication are performed that might, in turn, warrant a version bump to 4.0 as existing clients would no longer be wire-compatible.

If that turns out to be the case, I see a 4.0 release somewhat in parallel with 3.6.