Yes. Ralph
> On Dec 12, 2023, at 9:03 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > 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 >> >>
