RFR: clarify how to set the affects versions [v7]

[Alexey Ivanov]

On Mon, 4 Mar 2024 15:57:09 GMT, calnan <duke at openjdk.org> wrote:

>> moved together information on how the set the affects version and the meaning of the (Rel)-na and (Rel)-wnf labelss
>
> calnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates from feedback

Changes requested by aivanov (no project role).

src/guide/jbs-jdk-bug-system.md line 82:

> 80: 
> 81: 1) If an issue is applicable to a feature release N, it is assumed to be applicable to all (more recent) releases unless indicated otherwise (see [(Rel)-na](#usage-of-rel-na-label) below).
> 82:     - Note that if it is reported against an update release then all we can say is that it is applicable to all the following update releases, not necessarily the next feature release as it may have been introduced in an update.  Given this, it is always important to try and reproduce the issue in either the corresponding feature release as well as the mainline.

Suggestion:

    - Note that if it is reported against an update release then all we can say is that it is applicable to all the following update releases, not necessarily the next feature release as it may have been introduced in an update.  Given this, it is always important to try and reproduce the issue in the corresponding feature release as well as the mainline.

src/guide/jbs-jdk-bug-system.md line 92:

> 90: 
> 91: * The [Affects Version/s]{.jbs-field} isn't meant to be an exhaustive list of releases the issue is relevant to - it should initially be set to the release the issue was reproduced or identified on, and by implication it will be relevant to all releases past that point (see the [Usage of (Rel)[-na]{.jbs-label} Label](#usage-of-rel-na-label)). If it's later found to be applicable to an earlier release family then adding that earlier release is encouraged if the issue needs to be fixed in that release.
> 92: * Do not add additional release values to [Affects Version/s]{.jbs-field} for the same release family. For example, if there is the value [11.0.2]{.jbs-value}, don't add [11.0.5]{.jbs-value}, [11.0.7]{.jbs-value} etc. Adding an additional value for a separate release family where it's still reproducible, e.g. JDK [21]{.jbs-value}, is encouraged, especially if there is not currently a feature release value set, or, it has been a few releases since it was last reproduced/reviewed. For example, if the [Affects Version/s]{.jbs-field} is JDK [8]{.jbs-value}, but it is still relevant to the latest mainline release.

Suggestion:

* Do not add additional release values to [Affects Version/s]{.jbs-field} for the same release family. For example, if there is the value [11.0.2]{.jbs-value}, don't add [11.0.5]{.jbs-value}, [11.0.7]{.jbs-value} etc. Adding an additional value for a separate release family where it's still reproducible, e.g. JDK [21]{.jbs-value}, is encouraged, especially if there is no feature release value set, or it has been a few releases since it was last reproduced/reviewed. For example, if the [Affects Version/s]{.jbs-field} is JDK [8]{.jbs-value}, but it is still relevant to the latest mainline release.

Simply the condition; the comma after “or” seems unneeded.

-------------

PR Review: https://git.openjdk.org/guide/pull/119#pullrequestreview-1920235735
PR Review Comment: https://git.openjdk.org/guide/pull/119#discussion_r1514788065
PR Review Comment: https://git.openjdk.org/guide/pull/119#discussion_r1514794272