Re: Release notes / Dependency upgrades
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 > 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 > >
Re: Release notes / Dependency upgrades
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 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 >
Re: Release notes / Dependency upgrades
Side note, I used a command-line tool I wrote called 'jamira' to file most of these and have them appear as the person who originally filed the issue and did the work. A couple examples: jamira create issue --fix-version=9.0.0-M9 --reporter=ruelland --assignee=ruelland --type="Dependency upgrade" TOMEE "Jackson 2.13.4" jamira create issue --fix-version=9.0.0-M9 --reporter=rzo1 --assignee=rzo1 --type="Dependency upgrade" TOMEE "Apache Tomcat 10.0.23" I'll probably make myself a little convenience wrapper script for that so I can just type something like "upgrade.sh Apache Tomcat 10.0.23" Throwing the idea out in case anyone wants to do something similar. I'm not a fan of clicking :) Happy weekend! -David > On Sep 9, 2022, at 4:02 PM, David Blevins wrote: > > 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 > smime.p7s Description: S/MIME cryptographic signature
Release notes / Dependency upgrades
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 smime.p7s Description: S/MIME cryptographic signature
