Hi Volkan, On Tue, 12 Dec 2023 at 13:02, Volkan Yazıcı <vol...@yazi.ci> wrote: > > On Tue, Dec 12, 2023 at 11:47 AM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > * we lack a way to classify dependency updates. A concrete example: > > did the Commons DBCP2 bump to 2.11.0 change anything in > > `log4j-jdbc-dbcp2`? I don't think so, the artifact compiles with > > version 2.2.0 of the artifact. We are only stating that > > `log4j-jdbc-dbcp2` will **also** work with version 2.11.0. > > > > Exactly! Hence, it is clear that this is neither a bug fix, nor a > deprecation. That is, there is no ambiguity that this goes into a minor > release.
And here I don't agree. Dependabot upgrades provide **no** benefit to the generated JAR files. Even the bytecode is exactly the same as before the upgrade. What these changes provide is part of our "Secure by default" or "Up-to-date by default" feature: Log4j artifacts will never freeze our clients dependencies and will work with the newest versions of the libraries we depend upon. If you need to **manually** fix code for the upgrade to work (as you did for Jackson 2.16.0), then you can change the automatically generated entry from "fixed/upgraded" to "changed". > > I don't think this warrants a minor version bump. > > > > This is what I am trying to eliminate Piotr: opinions. When a person starts > thinking *"Shall this be a patch or minor release?"*, the outcome is > inherently subjective. We cannot completely get rid of subjective > assessment, but assist it with guardrails. These guardrails seem to follow the easy path: let's just do minor releases, so nobody will tell us we are wrong. If you add ".0.0" to all Google Chrome versions, Chrome will also follow semver to the letter. It just loses the spirit. > > The bump to JDK 17 was necessary, very useful for us, but users don't > > really care what JDK was used for compilation. > > > What? Users, that is, developers using `logging-parent` as their parent > project, do certainly care about this change. Why wouldn't they? This is > *not* a simple change. It took us months to bump the compiler in Log4j. I > think your statement has an incorrect assumption on who the users of > `logging-parent` are. Sorry, I was still talking about Log4j. For `logging-parent` users the requirement to use JDK 17 is a minor change, but `log4j-core` users do not care what JDK we are using for compilation. Therefore the switch to JDK 17 for compilation is not reason enough to bump Log4j to 2.23.0. > I have the impression that you want to classify library updates that don't > disrupt the user experience as a patch release. If there is nothing urgent > about them, why do a patch release at all? Isn't the point of a patch > release is to fix something, urgently? Piggybacking library updates into > patch releases defeats the purpose of patch releases and makes the line > between minor and patch releases blur, and that is the crux of our > disagreement. I would do a release at all if it only contains changes in the dependency versions. The only exception I would make is vulnerable dependencies, **if** we are affected by the vulnerability. If this is the case feel free to replace "fixed/upgraded" with "changed" in the changelog. In case a dependency upgrade does not influence the bytecode (i.e. our artifacts still work with the old version), I would simply disregard the upgrade when computing the required version dump. Piotr
