Re: Toward the next release and (proposed) release system changes


I'm fine with this.

- We'll define four new labels for GitHub PRs:
- Breaking Change
- Feature
- Fix
- Chore
- A PR must have exactly one of those applied for it to be merged
- The author of the PR can propose a label, in which case only one reviewer is required.
- If the author of the PR does not propose a label, two reviewers must sign off on the right label.
I suggest that the "mergeable" bot prints a reminder of this in the PR, unless the PR already has one of these labels. The following paragraph may be good to include in that reminder as a help to choose the correct label:

There's some judgement involved in this labelling process. An algorithmic change might change behavior enough to add a new feature (`Feature`) or cause issues for downstream code (`Breaking Change`). On the other hand, changing a class API by marking methods as deprecated for future removal is not a breaking change _yet_, and can be marked as `Fix`.

Set Github protections so master cannot accidentally be updated by PRs
Create the new branches: (we are temporarily leaving master as-is just this first time)
Can we developers stay on master and make PRs to master, or should we make PRs against some other branch? I'm asking to make sure I understand the process.


Join to automatically receive all group messages.