This (and other) bug updates are incorrect.

[Daniel D. Daugherty]

On 4/25/19 3:44 PM, Aleksey Shipilev wrote:
> On 4/25/19 9:02 PM, Daniel D. Daugherty wrote:
>> You misunderstand me. If the OpenJDK8u project wants a blanket designator,
>> then that project is welcome to create one. I do not recommend doing that.
>> A bug filed with a blanket version designator is initially useless to the
>> evaluator because the first thing you have to do is figure out the real
>> version where the issue was sighted. However, that's my opinion. I'm not
>> working on the OpenJDK8u project.
> You misunderstand me as well, I think.
>
> What I am saying that projects need blanket designators.

I think I understand that it is your opinion quite well.

And I have no problem if an OpenJDK Update project wants to
define such a version value.


> If there are none, people would
> invent/reuse the closest one, like the blank major revision. This will happen soon with somebody
> else, because the confusion is real; any many do this around JBS as well. More examples below.

I guess I'm not understanding why someone would file an issue
without specifying the exact version number they are seeing
the issue reproduce with.


>> Just to be clear: Please do not use '8' as a blanket version
>> designator value. That release value belongs to the OpenJDK8
>> project and _does not_ belong to the OpenJDK8u project.
> I wasn't aware there is such thing as "JIRA version belongs to a project".

It is the project that requests that the version values be added
to JIRA. Some projects have a version value for each projected
build, some have 'N-alpa', 'N-beta', and 'N'. It really is up to
the project to request the version values.

Dan


>> And as Phil requested, please fix the bugs that you recently
>> touched to no longer use '8'.
> Right, I dropped "8" from the issues that have the obvious affected-version. I would keep "8" for
> issues that are supposed to be reproduced with 8 GA.
>
> But, I have trouble fixing these oddly versioned ones:
>
> == "Update GIFlib library to the 5.1.8":
>    https://bugs.openjdk.java.net/browse/JDK-8220495
>
> Which "Affects Version" should it take? If we look back to issue history, there is a previous update
> happened here:
>    https://bugs.openjdk.java.net/browse/JDK-8155691
>
> Should it be 8u161 then?
>
> == "Xalan Update: Xalan Java 2.7.2":
>    https://bugs.openjdk.java.net/browse/JDK-8193830
>
> The issue already has 8u backports, but affects-version did not have any "8*" version. Which version
> to put there? The bug does not even link any related issues to see when was the latest update. I put
> "8" there this morning, which version should I put instead? I think this is one of those cases where
> "8" fits: it is not a bug, and 8 GA does not have new Xalan.
>
> == "Upgrade IANA LSR data"
>    https://bugs.openjdk.java.net/browse/JDK-8213294
>
> So it has backport to 8u221, which version to use then? 8u201? Or, using the logic from Xalan issue
> above, it is also proper "8"?
>
> == "[Windows] Exception if no printers are installed."
>    https://bugs.openjdk.java.net/browse/JDK-8212202
>
> It had backports to 8u212 and 8u231. It seems to be caused by JDK-8153732, which was backported to
> 8u212 and 8u231, which versions to use then? 8u212?
>
>
>
> -Aleksey
>
>
>