On Fri, 5 Sep 2025 13:43:04 GMT, Matthew Donovan <[email protected]> wrote:
>> Ah, you're right, I didn't think of this case! This approach will be easier >> then, I agree. >> >> Still, `ver.substring(idx+1)` may cause errors in cases like this [NSS >> 3.15.3.1 release >> notes](https://nss-crypto.org/reference/security/nss/legacy/nss_releases/nss_3.15.3.1_release_notes/index.html#mozilla-projects-nss-nss-3-15-3-1-release-notes). >> It will try to convert 15.3.1 to a double. Do you think changing to >> something like this would be worth it? >> >> >> String verSubstring = ver.substring(idx+1); >> String[] splitParts = verSubstring.split("//."); >> Double minor = Double.parseDouble(splitParts.length > 1 >> ? splitParts[0] + "." + splitParts[1] >> : splitParts[0]); > > That's a good point about 4-component version numbers. Frankly, I was hoping > that NSS never did that. I refactored the version parsing code to create a > `Version` record with major, minor, and patch versions. This way, individual > tests don't have to do the String parsing. If we end up with a test that has > to be skipped due to that 4th component, we can update the parsing > accordingly. Alternately, I can add it since I'm here now... what is that > fourth component called? Thank you for the changes! I'm not sure if it's even needed to be honest, it would be an overkill imo. I can't find the exact naming on the nss website, but I think the common one would be `major.minor.patch.hotfix` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27095#discussion_r2325202374
