Yesterday’s CppCon talk produced some excellent feedback and questions regarding how and when a company adopts a Beman library and what a library’s stability guarantees are.
The lifetime a Beman library can be divided into three distinct phases.
- Development phase: During this phase, the library is actively being developed but does not yet meet Beman standards. This means that documentation could be incomplete, testing may not be finished, or the library may not match the paper. While the library is not ready for extensive user testing, interested parties are welcome to contribute and provide feedback.
- Unstable release: Once the library meets all Beman standards, it enters the unstable release phase. Here, it is open for extensive user testing, and engineers are encouraged to integrate it into their codebases and provide feedback. It’s important to note that the API is subject to change during this phase.
- Stable release: Once a library becomes part of the official C++ standard, it enters the stable release phase. At this point, the API is stable, as backward-incompatible changes to standard libraries are rare. Projects can confidently use the library in production while awaiting an upgrade to their standard libraries.
This information is really useful from a Beman client perspective. Clients wanting to use Beman as a stand-in while waiting for standard library support can incorporate all stable libraries into their build. Those looking to give feedback on APIs still subject to change can pull in unstable libraries.
It is also worth considering using different namespaces for unstable and stable libraries (beman::library_name vs. beman::unstable::library_name). This way, large codebases could enforce, with tooling, limitations on unstable library usage.
We could also provide convenient automation for beman::unstable → beman:: → std:: transformations.