RFR: Follow-on update due to the introduction of caused-by links [v2]

[Roger Calnan]

On Thu, 27 Feb 2025 13:03:09 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> src/guide/jbs-jdk-bug-system.md line 84:
>> 
>>> 82: 1) If an issue is applicable to release N, then it can't be assumed that it is applicable to older releases less than N. It may be, but in general this is less important to know, as the majority of issues are only fixed in the latest feature release. If the issue is a crash or important in another way, then it becomes worthwhile to take the time to determine if it's relevant to earlier LTS releases.
>>> 83: 
>>> 84: Another aspect of an issue is when the feature, it's a part of, was added or removed from the JDK, which in either case limits the range of releases the issue impacts. Knowing that a feature was removed before the oldest currently maintained release means it can be resolved as [Won't Fix]{.jbs-value}.
>> 
>> Maybe "... when a part of the feature was added ...".  I'm not sure because that may change the intent.
>
> This could be more generalized since it doesn't only hold for features, but basically any code.
> "...is when the impacted code was added or..."

done

>> src/guide/jbs-jdk-bug-system.md line 128:
>> 
>>> 126: 2. No need to add additional releases as they are implied.
>>> 127: 3. Adding the occasional LTS release value is ok.
>>> 128: 4. Use N-na to indicate that the issue is no longer relevant from that release, which could be due to the feature or platform being removed or the code has been rewritten.
>> 
>> I think that "being rewritten" was correct since it parallels the earlier "being removed".
>
> Agree with Iris.

reverted the change

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

PR Review Comment: https://git.openjdk.org/guide/pull/143#discussion_r1987287658
PR Review Comment: https://git.openjdk.org/guide/pull/143#discussion_r1987288211