Hi David, thanks for the clean-up!
Regarding your questions: (1) I am +1 with limiting the scope of the issue type "dependency upgrade" to user-facing dependencies. Sadly, we cannot add new issue types like "build/test dependency upgrade" without involving infra but if we agree on tagging such issues with issue type "task" and they still occur in the release notes, I am fine with it. (2) Regarding the API version changes: The EE changes are implicit given via our major version but I agree, that the changes for MP (+ switch to Smallrye, etc) require a clear trace in our release notes. Maybe for the next milestone release it would be good to go with "New Feature/Improvement" instead of a "Dependency Upgrade" as we didn't previously relied on Smallrye for example. @Alex: We are on snakeyaml 1.31 since yesterday. That should include the fixes for CVE-2022-25857, CVE-2022-38751, and CVE-2022-38750. CVE-2022-38752 isn't fixed yet (at least judging from the fact, that the related Jira [1] is still open). Gruß Richard [1] https://bitbucket.org/snakeyaml/snakeyaml/issues/531/stackoverflow-oss-fuzz-47081 Am Samstag, dem 10.09.2022 um 07:41 +0200 schrieb Alex The Rocker: > Hello David, > > I agree that on (my) customer side, dependency upgrade of the > build/test tools aren't as important as dependency upgrades of code > actually part of TomEE runtime, so if it is possible to split the > list > in release notes between runtime dependencies upgrade versus > build/test-time ones, then it would be great ! > > Speaking about runtime dependency upgrades, how can we make sure that > recently announced CVE on snakeyaml will lead to an upgrade on next > TomEE 9 public release? > > Thanks, > Alex > > Le sam. 10 sept. 2022 à 01:02, David Blevins <david.blev...@gmail.com > > a écrit : > > Hey All, > > > > I did some cleanup of the dependency upgrade JIRAs for 9.0.0- > > M8. Here's what they look like: > > > > • [TOMEE-3800] - Apache DBCP 2.9.0 > > • [TOMEE-3999] - Apache MyFaces 3.0.2 > > • [TOMEE-4006] - slf4j 1.7.36 > > • [TOMEE-4009] - WSS4J 2.4.1 > > • [TOMEE-4010] - xmlsec 3.0.0 > > • [TOMEE-4018] - bcprov-jdk15on 1.70 > > • [TOMEE-4026] - Apache Johnzon 1.2.19 > > • [TOMEE-4030] - Apache Log4J2 2.18.0 > > • [TOMEE-4036] - EclipseLink 3.0.3 > > • [TOMEE-4037] - Eclipse Mojarra 3.0.2 > > • [TOMEE-4038] - Jackson 2.13.4 > > • [TOMEE-4039] - Hibernate 6.1 > > • [TOMEE-4040] - Apache Tomcat 10.0.23 > > > > The release notes: > > > > - > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12350618 > > > > Here's the logic I applied: > > > > - Normalize titles to "Foo 1.2.3" format and stripped out any > > "Upgrade" or "Update" prefixes > > > > - Remove the fixedVersion from obsoleted duplicates. If we have > > "Foo 1.2.3" and "Foo 1.2.4" marked as 9.0.0-M8, technically 1.2.3 > > is no longer in the release and could confuse people. > > > > - Split apart JIRAs that mention several upgrades so there's one > > JIRA per library > > > > - Changed the issue type of JIRAs that describe issues like "CVE- > > 123-4567" or "Problem with x on older versions of y" to be Bug, > > Task, etc and filed an explicit and separate "Dependency upgrade" > > > > - Put the full brand name in, e.g. "Apache Tomcat" instead of just > > "Tomcat" (maybe this is noisy, I probably won't be so picky with > > this next time. I was just trying it out) > > > > > > Some open questions: > > > > - We should probably make sure to list our API version > > changes. Either in Dependency Upgrades or as New > > Features/Improvements (or both) > > > > - IMO users don't care about upgrades for our build and are only > > concerned with things they use. What do we think about limiting > > use of "Dependency Upgrade" issue type to things that are in TomEE > > and therefore affect users? > > > > Thoughts? > > > > > > -David > >
