We maybe can simplify that by boiling it down to effectively restricting all limitations of our committer conventions to solely the main branch itself, while enforcing that any binary publications (aka releases and pre-releases) must ONLY happen from the main branch?
If not, we should extend your list by a fifth bullet that clearly tells everybody how a "working branch" is identified?
-Markus
Von: rest-dev [mailto:rest-dev-bounces@xxxxxxxxxxx] Im Auftrag von Jim Krueger via rest-dev
Gesendet: Samstag, 27. Januar 2024 20:34
An: Jakarta Rest project developer discussions
Cc: Jim Krueger
Betreff: [rest-dev] Proposed exception section to the Jakarta REST Committer-Conventions
In an effort to allow for accelerated development and prototype work for the proposed release-3.2 effort I’d like to add the following section to our Committer Conventions (https://github.com/jakartaee/rest/wiki/Committer-Conventions). Please vote and/or add suggestions.
Exception for “working branches”
Occasionally there may be a need for the community to collaborate and develop changes for the purposes of prototyping etc. In those cases a “working branch” may be created that will be managed with the following exceptions to the conventions stated above:
(1) There will be no minimum wait time to merge / close PRs.
(2) PRs may be merged / closed following review and approval by at least one committer (other than the submitter themself).
(3) A “working branch” will not correspond directly to any approved release plan.
(4) A “working branch” may later be associated with an approved release plan. At that time the content of the branch itself, and all future work contributed to it will be subject to the official Committer Conventions previously listed in this document