...
- Compatibility kind: check boxes for source, binary, and behavioral. Check which kinds of compatibility are impacted by this proposal. See Kinds of Compatibility for a detailed discussion on the different kinds of compatibility.
- Compatibility risk: minimal, low, medium, high
- Compatibility risk description: Issues with a compatibility risk of low, medium, or high should usually have a release note.
Scope: Selection of SE, JDK, and Implementation. This field is shared with JEPs. Anchor CSR Scope Field CSR Scope Field
...
Reviewed by: The other engineers who have reviewed the request. At least one reviewer is required. The reviewers must include one or more engineers familiar with the components being modified by the request. CSR group members may serve as reviewers, but it is not mandatory to have a CSR member as a reviewer.
Interface Kind: Java API, System or security property, Language construct, ..., add/remove command line option, ...
Check the boxes for which kinds of interfaces are affected by this requerequest.
Fix Version/s: The versions the proposal is targeted to change. For update releases, it is accepted to use one of the "pool" pseudo-release values such as "8-pool" to indicate some yet-to-be-determined release in the 8 update family. If known, a particular update release version may also be given.
Attachments: Files related to the proposal, such as webrev.zip of specdiff representing the changes. Engineers are strongly encouraged to put bug numbers into into the file names that are attached. For example, for JDK-8123456 instead of attaching "webrev.zip" attach "8123456-webrev.zip". If the request is updated, leave any old attachments in place and attach updated versions (8123456-webrev.1.zip, etc.). The CSR members may want to compare versions of the proposals and verify requested changes were made.