Piotr, could you give me a well-defined formula of your desired versioning scheme concerning minor/patch bumps?
On Tue, 12 Dec 2023 at 15:19, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > 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 >
