Open
Description
After the first crates-io release, it'd probably be good to visit a couple of "policy" items, discussing when necessary, making a decision when the answer is unclear, and documenting them to avoid future arguments.
For now, @Dirbaio is focused on the release, so let's just COLLECT items for now, and once the release is done, move these discussions to chat, or their own issues so things don't get tangled.
So, please DO add items you think should be discussed, please DO NOT start discussing these items yet.
Some items added in chat today:
- When/Should embassy crates go to 1.0? At some milestone? As soon as possible?
- How to handle "pls release" issues when PRs land on released crates? Full automation? Semi automation?
- Should we/How can we use cargo semver checks?
- Should we/How can we use release-plz
- Should we have a regular release schedule, if not fully automatic? (weekly? monthly?)
- Who can/should do/is allowed to do reviews, merges, and releases?
- Should we/How can we use CODEOWNERS?
- (more general topic: Dirbaio's bus/lotto factor)
- about "CHANGELOG.md":
- Should we ask (with CI check maybe?) contributors write down changelog(s) on each PR?
- Should "CHANGELOG.md" have "BREAKING"(major bump) / "ADDITION"(minor bump) / "MODIFY"(patch bump) sections?
- Should we rely on it to tell if a release is "breaking or not"?
- about "maintaining a major release after its released"
- eg. We have release 1.0, and after that we have some non-breaking commits and breaking commits.
- Should we just make a 2.0 release including all changes, or should we portal the non-breaking commits to 1.0 release and do patch and/or minor release(s)?