Next release 4.8.0 - October 11th Performed

[JuditKnoll]

Hello,

The last Spotbugs version 4.7.3 was released on 2022-10-15. Up until then there was a new release every or every other month made by @KengoTODA.
I have seen that @KengoTODA mentioned here, that he is not so active recently, but I couldn't reach the discussion he referenced (maybe I am not authorized to access it).

I was wondering whether there is a(n approximate) date for the next release?

I'm happy to help with the release process, if I can.

There are some open PR-s that I am currently working on, which I would be really happy if I could have in the next release.

• New bug type: ASE_ASSERTION_WITH_SIDE_EFFECT
• New bug type: AA_ASSERTION_OF_ARGUMENTS
• Add new rule set PA_PUBLIC_PRIMITIVE_ATTRIBUTE, PA_PUBLIC_ARRAY_ATTRIBUTE and PA_PUBLIC_MUTABLE_OBJECT_ATTRIBUTE

Who may I ask for a review?

Thank you for your answer in advance!

[hazendaz]

not sure, I'd like some help getting the rest of renovate PRs merged. Project is hard to work with IMO. It doesn't run well on windows if at all. The build system kind of ignores other platforms. Its gradle and I'm a maven user like most. If I can get it working in windows reliably, I'd be able to possibly get it released. I agree its way overdue. I've been running numerous patches on the spotbugs maven plugin against 4.7.3 for a while now and also want the update out soon, there is a lot in this since 4.7.3. But we do need some of the Renovate items addressed due to CVEs.

[JuditKnoll]

Thank you for your fast answer, @hazendaz, and I'm really sorry for my late one.
These are the oldest renovate PRs I found:

• fix(deps): update dependency com.google.guava:guava to v32 #2229
• fix(deps): update dependency org.apache.bcel:bcel to v6.7.0 #2278
• chore(deps): update plugin com.diffplug.spotless to v6.22.0 #2343
• chore(deps): update dependency gradle to v8 #2351
• chore(deps): update plugin org.sonarqube to v4 #2354

Which of theese do you think are the most important to have in the next release? Or are there some others, which I left out and are crucial to the new release?

I use both Windows and Linux, and can verify that spotbugs doesn't build in Windows as flawlessly as it does in Linux, but haven't looked in depth at the exact problem(s) yet.
I'm also more familiar with maven, but try to help and contribute something useful to the project.

I'm also quite new to the project, and I not sure, what is the exact process for fixing a problem, which @renovate already has a PR for? Should I create a new PR to the branch the bot created?

As far as I can see, you are one of the most active members of the community. Are you the one, who is responsible for the release as well?

[hazendaz]

I think the first two are more important. Others would be nice to have.

[JuditKnoll]

Thank you for looking at and merging my PRs.

I managed to find a solution to the guava dependency problem, and it got merged.
Looked into the bcel dependency issue as well. To solve the problem completely we will need a newer, currently unreleased version of bcel.
The spotbugs version 4.7.3 had bcel 6.5.0, which has a CVE vulnerability ( GHSA-97xg-phpr-rg8q ).
The current spotbugs master has bcel 6.6.1, which has no known vulnerability AFAIK.
In the discussion about the CVE in apache bcel ( #2251 ), several people expressed interest in connection with the release, which solves this problem.

I propose that the next SpotBugs release includes bcel version 6.6.1 instead of waiting for 6.7.1. What are your thoughts on this?

• Are there any issues or PRs that are blocking the next release?
• Are there features that the community is waiting for?

Additionally, I noticed that the SonarCloud Code Analysis has been failing.

• Is a successful SonarCloud Code Analysis required for the release?
• If so, is there a plan to run all the checks that are run on the master on the PRs as well (even if we have to do this manually)?

I'm happy to help with anything I can. On my end, the current master builds successfully on both Linux and Windows.
Thank you for your time and consideration. I look forward to your feedback.

[JuditKnoll]

@hazendaz @ThrawnCA Do you know about any issues, PRs or problems that are blocking the next release?

[hazendaz]

I don't think anything is really blocking at this point, however, I have no clue how to release this. I took a look a while back before you got windows working and at that time the documentation seemed old on releases. Others have been releasing it to this point. I can try to look but I'm not well versed on gradle so hoping other contributors see this and can help out :)

[JuditKnoll]

I found the RELEASE_PROCEDURE.md, the release.yml, and checked the earlier releases (e.g. PR for 4.7.3). However the .travis.yml (referenced by the RELEASE_PROCEDURE.md) doesn't exist anymore, the processes got moved to GitHub Actions (see the PRs mentioned in #1123). But I think only KengoTODA is authorized to do some steps.
@KengoTODA What do you think, is spotbugs ready for the 4.7.4 release?

[hazendaz]

Thanks that is what I was seeing. I have the role to release. He gave me some pointers a year ago to release the gradle plugin. Looking again it appears probably the same. I'll look this weekend and work to cleanup the release steps. The eclipse plugin is released on all merges to mainline now. So only need worry about main code. Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Judit Knoll ***@***.***> Sent: Wednesday, June 28, 2023 7:08:26 AM To: spotbugs/spotbugs ***@***.***> Cc: Jeremy Landis ***@***.***>; Mention ***@***.***> Subject: Re: [spotbugs/spotbugs] Next release (Discussion #2417) I found the RELEASE_PROCEDURE.md<https://github.com/spotbugs/spotbugs/blob/master/RELEASE_PROCEDURE.md>, the release.yml<https://github.com/spotbugs/spotbugs/blob/master/.github/workflows/release.yml>, and checked the earlier releases (e.g. PR for 4.7.3<#2216>). However the .travis.yml (referenced by the RELEASE_PROCEDURE.md) doesn't exist anymore, the processes got moved to GitHub Actions (see the PRs mentioned in #1123<#1123>). But I think only KengoTODA is authorized to do some steps. @KengoTODA<https://github.com/KengoTODA> What do you think, is spotbugs ready for the 4.7.4 release? — Reply to this email directly, view it on GitHub<#2417 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHODIYR5IFN2P6YKCVL77TXNQGCVANCNFSM6AAAAAAXMIP4NA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[JuditKnoll]

If you have the role to release, then you should be authorized to do every step.
Did you manage to look into the release steps?
Is there anything I can help you with?

You have mentioned that you received some pointers about the gradle plugin. Looked into the *.yml files in that repository, but couldn't find release.yml or any similar file, which describes the release steps in detail to compare it with the mainline.
Would you mind sharing some info?

[hazendaz]

Haven't had a chance to look yet. Also seems steady flow of new code keeps coming in that you have been extremely instrumental in getting in. Will try to look this coming weekend.

[baloghadamsoftware]

Hello,

Please do not forget that several new features (detectors) were merged into master recently. Until now, it was the rule that in case of new features the second version number was incremented. Thus, if this rule still holds, the next release should be 4.8.0 instead of 4.7.4..

[hazendaz]

Agreed next release will be 4.8.0 Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Balogh, Ádám ***@***.***> Sent: Thursday, June 29, 2023 9:27:22 AM To: spotbugs/spotbugs ***@***.***> Cc: Jeremy Landis ***@***.***>; Mention ***@***.***> Subject: Re: [spotbugs/spotbugs] Next release (Discussion #2417) Hello, Please do not forget that several new features (detectors) were merged into master recently. Until now, it was the rule that in case of new features the second version number was incremented. Thus, if this rule still holds, the next release should be 4.8.0 instead of 4.7.4.. — Reply to this email directly, view it on GitHub<#2417 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHODI7W7H6JNXUUVGKWQPTXNV7DVANCNFSM6AAAAAAXMIP4NA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[vghero]

Thanks guys for taking care of a new release ❤️. We are also looking forward to it because of #2289. I think also others would be happy to see that supported soon. Any estimation already :D?

[hazendaz]

Clear and transparent and very my opinionated view!

No estimate at this time. Given the original release managers for this project are not available, its likely up to @JuditKnoll and I to figure it out. Maybe @ThrawnCA might assist not sure. And likely me that has to do the release as I have access to push the distributions to central. I'm not that great with gradle as I barely use it but getting better. But also there are a number of issues with these builds that don't function cross platform well (and I'm a windows user). So we are working on it but in meantime fixing up a lot of general issues as well. Its likely to be a little while. Once release is figured out, expect we get back to normalcy here and get releases out like they use to be done. From my perspective, I'm the release manager on the maven plugin part and I've already made 5 patches on top of 4.7.3 which is silly and why I'm over here now. And honestly I expect I'm going to do patch 6 over there before this gets out.

Some things I'm expecting before a release

• Contributors keep bringing in new stuff
• We probably should discuss dropping jdk 8. By time we get this out jdk 21 is LTS so it makes really no sense to try to support obsoleted versions. Sure jdk 8 still has Oracle support but that is paid for and well...you know we are not paid.
• We need builds on GHA working across windows, mac, linux not just linux. Its sloppy there IMO as it ignores contributors that exist. Same reasons windows was entirely broken in usage to build. Thanks to @JuditKnoll for fixing that. We need to break down hard requirements so its easier for contributors to contribute and we certainly need to make gradle not so dumb that it fails spotless and tells users to run spotless as that should be automatic (duh - gradle is certainly misconfigured there and how many times do we tell people to deal with our nonsense).
• We need to thoroughly review all tickets, get rid of duplicates, close old ones etc. Just a week back we had north of 500 tickets and many were bot spam. Again IMO, that is sloppy to have so many tickets basically being ignored or allowed to pile up and sure we could use a stale bot but I don't want to do that as some of those old ones are in fact very valid as I just fixed one in last few days in fact.

If there is anyone on this overall discussion that can start helping contribute to clean up the builds, fix issues, etc, that would be greatly appreciated it. I'm lending what time I have but its not a lot. The more others contribute the more it helps keep us engaged and trying to make this move again. I personally feel like history is repeating here like it did in 2016 era except this time we have the proper access but just missing out on help from those that are certainly more familiar with this process.

As 'wu-tang clan' said one time, 'all in together now', So it will take all of us working to make this ship right itself. I ultimately want our cadence to be releasing monthly.

[baloghadamsoftware]

Hello,

About dropping JDK 8. I made some experiments a year ago about the compatibility of SpotBugs with Java 11. That time there was a Gradle problem which prevented it but now it works without issues. Here is my PR: #2492. I think that this change is also needed for the upgrade to JDK 17.

[JuditKnoll]

I was wondering about what should we aim for as the next release: 4.8.0 or 5.0.0?
I've been considering our options for the next release, and I find the following points relevant:

Regarding Issue Review:

• I agree that issues need to be reviewed, but perhaps not all before the next release. We could set a goal, threshold, or deadline (e.g., review every open issue updated in the last year, currently just under 100 issues).
• Older issues may take more time to verify and may not be as urgent.

Regarding Multiplatform Build:

• I've started working on a multiplatform build GitHub action and will create a PR shortly. While useful, I see this as a nice-to-have feature.

About 5.0.0:

• We have a milestone for 5.0.0 containing breaking changes: Milestone 15.
• Two of the three issues in this milestone currently lack PRs or solutions (Issue 1324, Issue 1100). Are these blocking changes for 5.0.0, or can they be postponed?
• Some PRs seem suitable only for 5.0.0 (PR 2055, PR 2492), but they aren't listed among the planned breaking changes.

4.8.0 vs. 5.0.0:

• We need to identify which issues, PRs, and features are blocking for 4.8.0 and 5.0.0.
• The only blocking PR for 4.8.0 seems to be PR 2278, waiting for the new bcel release with PR 221 merged.

Proposal: the next release should be 4.8.0, not 5.0.0, because

• There will be less blocking issues.
• It's easier for to users to adapt if the new version has less, smaller changes.
• There are merged PRs, which several users are waiting for.
• There are already plenty of changes, fixes, new features merged for a release.
• Even the release itself without the original release managers could be quite a challange, it may be a bit less troublesome if it is not a new major version.

[JuditKnoll]

Opened the PR I promised about the multiplatform build Github action: #2507

I won't be available until 28th August. After that, please let me know, how can I help with the release (if the new release won't be out yet).

[hazendaz]

This sounds good. Keep to jdk 8 for 4.8.0. Do we need to back anything out or pretty much ready to go? Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Judit Knoll ***@***.***> Sent: Thursday, August 10, 2023 4:12:12 AM To: spotbugs/spotbugs ***@***.***> Cc: Jeremy Landis ***@***.***>; Mention ***@***.***> Subject: Re: [spotbugs/spotbugs] Next release (Discussion #2417) I was wondering about what should we aim for as the next release: 4.8.0 or 5.0.0? I've been considering our options for the next release, and I find the following points relevant: Regarding Issue Review: * I agree that issues need to be reviewed, but perhaps not all before the next release. We could set a goal, threshold, or deadline (e.g., review every open issue updated in the last year, currently just under 100 issues). * Older issues may take more time to verify and may not be as urgent. Regarding Multiplatform Build: * I've started working on a multiplatform build GitHub action and will create a PR shortly. While useful, I see this as a nice-to-have feature. About 5.0.0: * We have a milestone for 5.0.0 containing breaking changes: Milestone 15<https://github.com/spotbugs/spotbugs/milestone/15>. * Two of the three issues in this milestone currently lack PRs or solutions (Issue 1324<#1324>, Issue 1100<#1100>). Are these blocking changes for 5.0.0, or can they be postponed? * Some PRs seem suitable only for 5.0.0 (PR 2055<#2055>, PR 2492<#2492>), but they aren't listed among the planned breaking changes. 4.8.0 vs. 5.0.0: * We need to identify which issues, PRs, and features are blocking for 4.8.0 and 5.0.0. * The only blocking PR for 4.8.0 seems to be PR 2278<#2278>, waiting for the new bcel release with PR 221<apache/commons-bcel#221> merged. Proposal: the next release should be 4.8.0, not 5.0.0, because * There will be less blocking issues. * It's easier for to users to adapt if the new version has less, smaller changes. * There are merged PRs, which several users are waiting for. * There are already plenty of changes, fixes, new features merged for a release. * Even the release itself without the original release managers could be quite a challange, it may be a bit less troublesome if it is not a new major version. — Reply to this email directly, view it on GitHub<#2417 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHODI4NRYQWMGSBEOXZSSLXUSJVZANCNFSM6AAAAAAXMIP4NA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[JuditKnoll]

I have no idea. The necessary PR is still open. The last release was on 6th December 2022, before that the release was more frequent, but I couldn't find any real pattern in the release times.

[gtoison]

Maybe #2506 can be merged before releasing?

[Jeeppler]

@gtoison #2506 seems to be merged.

Apache Commons BCEL is currently at version 6.7.0. Version 6.7.0 is not vulnerable to CVE-2022-42920. Are there any other issues which block the release?

[JuditKnoll]

@Jeeppler However, Apache Commons BCEL 6.7.0 is not vulnerable to CVE-2022-42920, spotbugs can't be updated to that version because of a bug in BCEL. See that the build at #2278 is failing. There is already a PR solving this in BCEL (apache/commons-bcel#221), but it's not merged yet.

[Jeeppler]

@JuditKnoll thanks for the clarification.

[yomerchavdar]

Gib next Release, we need it for the security update, yes please (つ◉益◉)つ

[JuditKnoll]

I looked into the release process once again, and even released a version on my fork (using a simplified release.yml, see JuditKnoll#2) to test the release procedure (see JuditKnoll#3, release, run of the releasing job). Found an issue when trying it out, created #2554 PR to solve.

According to the RELEASE_PROCEDURE.md file these are the following steps to the release:

1. Update version info
   • This one needs to be done manually in a PR from the spotbugs/spotbugs repository, which has a commit with a tag (similarly to Release 4.7.3 #2216).
   • I propose the values to be the following to the next release:
     • version: 4.8
     • full_version: 4.8.0
     • maven_plugin_version: 4.8.0.1
     • gradle_plugin_version: 5.1.3
       • For the last release it was the newest version at that time, not the next version.
2. Release to Maven Central
   • It's fully automated by the build step of the release.yml in the name of Kengo Toda (eller86 seems to be his nickname). The sonatype password is in the secrets.
3. Release to Eclipse Update Site
   • It's fully automated by the Deploy eclipse (or Deploy eclipse-latest or Deploy eclipse-candidate) step of the release.yml.
4. Release to Eclipse Marketplace
   • It's needs to be manually done.
     @hazendaz Do you have permission to the Eclipse Marketplace page to release?
     If not, @iloveeclipse can you please help with this one?
5. Release to Gradle Plugin Portal
   • However RELEASE_PROCEDURE.md file states that it's automated, I think it's needs to be started under spotbugs-gradle-plugin.
6. Update installation manual
   • However the RELEASE_PROCEDURE.md states that there are links to the released binaries in docs/installing.rst, there isn't any. Nothing to be done.
7. Release to ReadTheDocs
   • This one simply refers the docs/README.md. I think in the version page the stable version needs to be updated manually.

So, what's needs to be done to release a new version?

1. We need a new PR from a new branch under the spotbugs repository with a tag to start the release procedure. The Release 4.7.3 #2216 is a good example to this. See the proposed values to the versions earlier.
2. The release procedure (defined in release.yml) starts when the tag is pushed.
3. The freshly released eclipse plugin needs to be uploaded to the Eclipse Marketplace page.
4. The stable version under the ReadTheDocs version page needs to be manually updated.

+1. Create a PR under spotbugs-gradle-plugin to update to the newest spotbugs version.

Did I miss out or misunderstand anything?
Is there anything (other than #2554) blocking the release?

[hazendaz]

I think we are good for a release, I need to review the info @JuditKnoll put together here. Not sure if everyone was also aware the eclipse plugin is released constantly, every time master changes. I've been running with newer copies and delivery production built Eclipse with this plugin included at recent versions for bulk of the year. Possibly we can make the release this weekend...

[JuditKnoll]

@hazendaz Did you run into any blocking issue? Was there anything unclear in my message? Is there anything I can help you with?

[hazendaz]

Hi @JuditKnoll I plan to try to do this over this weekend.

[talios]

@hazendaz will that release include any JDK21 support changes as well?

[JuditKnoll]

@talios AFAIK updating asm dependency to 9.5 should solve the JDK21 problems, which is already merged to master (#2391), so yes, the next release should work with JDK21.

[hazendaz]

Didn't get release out, still messing with spotless + git EOL markers. Basic gist is we need spotless upgraded but I'm not understanding the issue faced where classes are missing. Will continue looking into it this week.

[JuditKnoll]

Are you sure that the spotless upgrade is necessary for the release?
I tried to look into it a few times, but couldn't solve the issue. Commented my findings earlier to the relevant PR (#2343).

[hazendaz]

I've solved spotless issue based on how it's done on the gradle plugin. I'm convinced there is class path resolution issued but was able to resolve to latest version. I've also corrected git attributes and spotless config to standards. All those issues were related. Now all source will auto determine line endings from git as expected. I'll get PR up shortly along with trimming whitespace added. Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Judit Knoll ***@***.***> Sent: Thursday, September 28, 2023 6:50:19 AM To: spotbugs/spotbugs ***@***.***> Cc: Jeremy Landis ***@***.***>; Mention ***@***.***> Subject: Re: [spotbugs/spotbugs] Next release (Discussion #2417) Are you sure that the spotless upgrade is necessary for the release? I tried to look into it a few times, but couldn't solve the issue. Commented my findings earlier to the relevant PR (#2343<#2343>). — Reply to this email directly, view it on GitHub<#2417 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHODIZGVWXYRQFHXHNQAJLX4VI6XANCNFSM6AAAAAAXMIP4NA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[abishek75]

Thanks @gtoison for the clarification, Can some-one confirm the date for 4.8.0 which was planned for end-September, also JDK 17 running version i.e. 6.0.0 is still planned for end-January 2024 ?

[gtoison]

The project is maintained by volunteers so it's hard to give accurate release dates.
I'm also unsure why you're asking about JDK 17: SpotBugs can already analyze code compiled by JDK 17 and it can run with JDK 17. Can you please clarify what's your question?

[abishek75]

Hi @gtoison @hazendaz The understanding we have had is that 4.7.3 version supports JDK 1.8, support for higher versions are being planned in 5.0.0 and 6.0.0 versions in next months.

[iloveeclipse]

@abishek75 :

The understanding we have

Is completely wrong... Please read above. Currently released SpotBugs can run on any released JVM > 1.8 and can analyse any bytecode generated with up and including JLS 20. Planned next SpotBugs release will additionally support analysis of the bytecode generated with the JLS 21.

[abishek75]

Thanks, requesting @hazendaz to reconfirm purpose of 5.0.0 and 6.0.0 planned releases.

[hazendaz]

There were some issues generally getting the build to work locally which are now resolved. I am still looking at a few minor issues mostly with gradle not working the same on local vs github. I more or less have it ready to go but want to be certain before cutting release. I'll adjust the milestone delivery date tonight for 4.8.0 as to where i think it will be. The future dates will remain as is. Given this is first release post long term maintainers releasing I believe it's best we get it right and don't end up patching too quickly. Once this is resolved we will be back on regular cadence going forward. Outside of all items coming with this, the current release works fine through jdk 21 provided asm overridden. And for eclipse plugin the snapshot is available after every merge. Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: abishek75 ***@***.***> Sent: Tuesday, October 3, 2023 6:47:54 AM To: spotbugs/spotbugs ***@***.***> Cc: Jeremy Landis ***@***.***>; Mention ***@***.***> Subject: Re: [spotbugs/spotbugs] Next release (Discussion #2417) Thanks @gtoison<https://github.com/gtoison> for the clarification, Can some-one confirm the date for 4.8.0 which was planned for end-September, also JDK 17 running version i.e. 6.0.0 is still planned for end-January 2024 ? — Reply to this email directly, view it on GitHub<#2417 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHODI4M65NOP22JL6HTOLLX5PUNVAVCNFSM6AAAAAAXMIP4NCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TCNZUGMYDS>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[hazendaz]

Hi, I've gotten past the concerns I had on windows. Gradle was not using the jvm I had set for usage and was dropping to java 17. I had put up more builds on my fork and couldn't understand at first why jdk 21 failed. While the product is compatible - gradle is not / kotlin is not. That is likely important for users to understand so noting that here.

Now, as far as release. I have 2 tasks I've added to issues I'll finalize for this and do the release this weekend.

So for releasing, I have no issues doing that either. Learned over last week I pretty much have global access here so I can write directly to any branch as far as I can tell and/or modify rules if needed. So what I plan to do is cut a branch called 'release/4.8.0' similar to prior releases, put the files on there that matter. I am not going to document the gradle or maven plugins as updated as that would be false info at time of the core. I'll update those later. I'll then tag that commit and let everyone review that before doing a local merge forwards and pushing so its not squashed. Expect sometime Saturday to start this with release attempt then on Sunday. I've updated the milestone to reflect that.

Post the release, I think we just continue general BAU with nothing massive for a few weeks while that makes the rounds to everyone. By say end of November if we hear no major issues requiring additional releases, I plan to improve upon eclipse formatting along with more modern line sizing (120). That affects most all files and does make most things look better. I have that done already. Post that, we can start moving onto jdk 11 as well and start cleaning up the code. I've been pretty deep in the code and it does need a lot of TLC.

[iloveeclipse]

I plan to improve upon eclipse formatting along with more modern line sizing (120). That affects most all files and does make most things look better.

Please don't do that. This will mostly break git blame and with that also understanding which piece of code is doing what. Most of the code is poorly documented and one of essential sources of understanding is to check which commit changed this line and get the context. After reformatting everything we will lose that. So I strongly disagree to do a full source re-formatting.

Post that, we can start moving onto jdk 11 as well and start cleaning up the code.

I've commented on that topic already - it doesn't make sense to move to the old Java 11 that is already two Java LTS releases behind. Switching to Java 17 is more natural choice, as Java 21 is pretty fresh to be widely used and so Java 17 is the last "commonly" used LTS Java.

[gtoison]

I agree that breaking git blame by reformatting is not worth it

[JuditKnoll]

I also think that format changes are not worth of losing the info provided by the git blame.

[hazendaz]

Git allows to skip a global formatting change so git blame and all else is fine. Maven has been doing just that across all their repos. I'll show that when it's done. Won't be this release. Was just noting it. To git it will simply ignore that change by adding commit id to one of the git files. Maven recently added auto formatting to all their projects and added that at same time. Basically git then doesn't show the diff. It's a special case for such a purpose. Ultimately it does matter. At some point spotless won't work if we keep thinking formating from nearly a decade back is great. At some point that ability would go. Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Judit Knoll ***@***.***> Sent: Wednesday, October 4, 2023 4:40:01 AM To: spotbugs/spotbugs ***@***.***> Cc: Jeremy Landis ***@***.***>; Mention ***@***.***> Subject: Re: [spotbugs/spotbugs] Next release 4.8.0 - October 8th ETA (Discussion #2417) I also think that format changes are not worth of losing the info provided by the git blame. — Reply to this email directly, view it on GitHub<#2417 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHODI7XFM4SW6TCXKHMC7LX5UOGDAVCNFSM6AAAAAAXMIP4NCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TCOBUGE4TM>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[hazendaz]

Release is completed! The release simply came down to doing the 2 commits and pushing them manually. PR isn't really needed nor matter since it works off the tag which would not be on the PR anyways. I presume only reason to raise PR would be to make sure it looks correct. All seemed to work well other than a github warning on deprecated items in the build file (I've fixed but not pushed up).

So I think we are done here other than we need to review the process again and make sure documentation properly matches. From here this is a piece of cake. We do need to push out the gradle and maven plugins to match still.

[hazendaz]

Sonatype is manual after the fact. I'm doing that now.