As a library, Seastar aims to maintain backwards compatibility in terms of the source (application code should continue to build with newer versions of Seastar) and any binary protocols that Seastar exposes (e.g. rpc).
Link compatibility is not maintained - you cannot link an application built with one version of Seastar with another version of Seastar.
Seastar will support the last two standards approved by the ISO C++ committee. For example, after C++20 is released, Seastar supports C++17 and C++20. Similarly, when C++23 is released, Seastar will support C++20 and C++23.
Some features may only be enabled for newer dialects.
Seastar supports Linux. There is no known minimum kernel version, but very old kernels might not work. Performance can be significantly better for newer kernels.
Filesystem implementation quality can have significant effect on file I/O performance. XFS is known to be working, ext4 may work well too. Test your filesystem and kernel versions to be sure.
Patches for new platforms (e.g, Windows) are welcome.
Seastar supports gcc and clang. Ports to other compilers are welcome.
The last two major releases of a compiler are supported (e.g. gcc 11 and gcc 12). Patches to support older versions are welcome, as long as they don't require onerous compromises.
Occasionally, we discover that we took the wrong approach with an API. In these cases we will offer a new API and tag the old API with the [[deprecated]] attribute. The deprecated API will be removed after a transition period (which can vary depending on how central the deprecated API is).
Rarely, we have to make breaking changes. We try to limit those, but sometimes there is no choice.
To support a transition period for breaking changes, Seastar offers the Seastar_API_LEVEL cmake variable (and corresponding --api-level configure.py option). An API level selects different versions of the API. For example.
- Seastar_API_LEVEL=1 selects an old version of the server_socket::accept() API that returns a variadic future (which is deprecated)
- Seastar_API_LEVEL=2 selects a new version of the server_socket::accept() API that returns a non-variadic future
- Seastar_API_LEVEL=6 makes futures non-variadic
- Seastar_API_LEVEL=7 unifies CPU scheduling groups and IO priority classes "while at it" file_impl API is forced to accept io_intent argument
Applications can use an old API_LEVEL during a transition period, fix their code, and move to the new API_LEVEL.
Old API levels only live for a transition period, so if you are using an API level below the latest, you should upgrade quickly.
Note the application should not refer to the api_vN
sub-namespaces that Seastar defines as part of the API_LEVEL
mechanism; these are internal.
Identifiers in the seastar::internal namespace are not subject
to source level compatibility and are subject to change or removal
without notice. In addition the api_vN sub-namespaces are also
internal.
Some identifiers predate the internal namespace, and are only exposed accidentally. These can also be removed or changed. Exposed identifiers are documented using doxygen, but not all exposed APIs are documented. In case of doubt, ask on the mailing list.