The birth of X4 is a very recent event, and a certain cool-down period should be allowed to calmly consider this important document.
That said, here's the draft I have in my mind:
- "Building Consensus"
- Technical discussions should happen in normal Issues and Pull Requests. This may include a breaking change which does not seem to require consensus.
- Issues should be limited to the subject which maps 1:1 to the (potential) Pull Request. Otherwise, it should go to the Discussions
- For sensitive matters, require users to first build the consensus in GitHub Discussions. This would be our primary process to build consensus for X4. After the consensus is reached, spirit maintainer will post the result to the Boost developers mailing list. We direct the feedback to the original thread.
- This policy also applies to the Boost Developers. In the Boost Organization, sublibraries can define how the library would be maintained. We define that we must first build a consensus on our GitHub Discussion, if it involves some technical issues in Spirit.
- Encourage users to use X4 only in applications that aims to support the recent C++ versions
- Current minimal C++ version
- Policy on deciding the minimal C++ version
- Current supported toolchains
- Policy on deciding supported toolchains
- Internal dependencies
- Boost.Variant will be replaced with something in the future
- Boost.Fusion is ditto
- Breaking changes
- Breaking changes involving security issues will be merged immediately without notification (for obvious reason)
- Ordinary breaking changes
- ABI breaking changes (we will not provide ABI guarantee; same as the C++ standard)
- Deprecation policy
- Deprecation will be either marked as
[[deprecated]] or preprocessor warning is emitted
- Deprecated features will be removed after 2 major Boost releases
- We may occasionally undeprecate features for some good reason
- Design policy
- We don't accept adding customization point without unit tests
The birth of X4 is a very recent event, and a certain cool-down period should be allowed to calmly consider this important document.
That said, here's the draft I have in my mind:
[[deprecated]]or preprocessor warning is emitted