As we’ve previously discussed, we need to have another doc (e.g., named BEMAN_PROCESS.md)t, where we state complementary rules/guidelines/best practices etc.
@leads , please help to move with a minimal skeleton of BEMAN_PROCESS.md into main, as the Beman libraries lifetime section, as I plan to use it on https://www.bemanproject.org/.
I would recommend formalizing the release process after we have had experience releasing any library to a non-beman audience. And after we gather sufficient feedback.
Before we have sufficient release experience we should document them as verbal as possible and evaluate projects on a case by case bases for the website (e.g. this label themselves are unstable).
I don’t quite agree with the life-cycle defined and I personally think the status should be tied with revisions of the papers more closely. But I think the main point I want to say is that we need more experience with release cycles before we try to fit all the libraries into little boxes.
As far as I understand, the current promise beman provide for library authors is to get feedback early during the standardization process. We should encourage use of a library when paper is still in revision stage to get feedback (to authors, libraries are most useful when they are in BEMAN DEVELOPMENT doesn’t quite make sense to me), a library should be able to label themselves as “stable for paper revision x” when they have aqueduct testing, and is beman conforming. I believe this will attract more people to try-out the library and give feedback.
Another complication would be if the main paper for the implementation of a library is stable for the next release, but another paper that is still not stable that will have an effect if voted in (e.g. static_vector may change constexpr constraint due to trivial union), I think we should allow something like a “mainly stable” flag based on how much of a impact the other paper is (e.g. inplace_vector could be “mainly stable” before trivial union as trivial union only broadens the constraints of inplace_vector).
My main point is, I think we should define stuff like LIBRARY_STATUS as enums after we gather enough experience, especially given our focus of attracting feedback for working papers and the fact that release labels are really hard to change.
