I have to agree with Piotr’s example. Simply upgrading a dependency doesn’t, on its own, change any code in Log4j.
I see three possible solutions for this: 1. Do not allow any dependency updates until a “scheduled” mentor release (once every 2 or 3 months). Frankly I’d be fine with this except when a dependency has a major security vulnerability. 2. Change all dependency versions to be ranges such that they don’t require a release for users to include new dependency releases. (I cannot really recommend doing this). 3. Add a new type to represent dependency updates. This would also not require a minor release. This is really the most appropriate fix as updating a dependency is not a change to anything in Log4j. I would suggest adding another enumeration named “update”. Ralph > On Dec 12, 2023, at 7:19 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Volkan, > > On Tue, 12 Dec 2023 at 13:02, Volkan Yazıcı <vol...@yazi.ci > <mailto: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
