Page History

...

Q: How should I get CSR review for multiple release trains?
A: Say you want to get an interface change into JDK N and later decide the change is also desirable and appropriate for the JDK (N-1) update release and that update release is using the CSR process. First a CSR should be created from the main bug targeted at JDK N. Afterward, if a backport of the main bug covering JDK (N-1) does not already exist, a backport of the main bug covering JDK (N-1) should be created. Then, a CSR can be created from that backport. The CSR for the backport should explicitly state how the interface change for the backport relates to the interface change for the main release: either the interface change is the same or, if it differs, what the difference is.

If the change is being backported to multiple prior release trains and the delta is same in each train, multiple values can be given in the "Fix Version/s" field of the backport CSR. The values used for "Fix Version/s" can be non-specific "pool" values, such as "17-pool" to indicate some release in the 17 update train. If the delta of the backport is differs in different release trains, each distinct delta should have its own CSR.

If it is recognized that a change should be backported when the CSR review of the feature release is initiated, the CSR for the feature release can also list multiple release for the update releases of interest, subject to the conventions described above.

Q: Under what conditions does a CSR need to be filed for a purely behavioral change?
A: Using qualitative terms, a CSR for a behavioral change should be filed if it is estimated enough developers or users would be sufficiently impacted by the change that it should get additional consideration or documentation. A judgment call is involved. If assistance is needed in determining whether or not a CSR needs to be filed, ask the CSR representative for that area or the CSR chair.

...