Ralph, do you mean if all changes are a subset of bug fixes, deprecations, or updates, then it is a patch release?
On Tue, 12 Dec 2023 at 16:23, Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 > >
