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. > 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. > * we lack a type to classify internal changes to the build system. > 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. > Lacking a special "upgraded" type I would classify those changes as > "fixed", hence a patch level change. > 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.
