This is going to be somewhat subjective and may be on a case-by-case basis, but here are my thoughts:
On Mon, Dec 11, 2023 at 2:17 PM Volkan Yazıcı <vol...@yazi.ci> wrote: > > I think this is where we have different ideas. > Robert, could you elaborate on *"change/fix behavior without adding new > method"*, please? For instance, does this cover the following changes? > > - Upgrading a dependency whose patch version is bumped (no behavior > change on the parts we use the dependency) > - Upgrading a dependency whose minor version is bumped (no behavior > change on the parts we use the dependency) > - Upgrading a dependency whose major version is bumped (no behavior > change on the parts we use the dependency) > - Upgrading a dependency whose major version is bumped (no behavior > change on the parts we use the dependency, though the runtime requirements > of the dependency has changed, e.g., started requiring Java 17 instead of > Java 8, etc.) > - `sum(a,b)` has changed from `a+b` to `a-b` (behaviour change, no new > method) > - `sum(a,b)` has started using GPUs (no change visible to the user, > though substantial implementation change) > I think all of these would be either a patch/minor version change - semver is showing users of your library(in this case log4j) what YOU provide, not what you depend on. The more difficult/large the change is(using GPU, bumping a dependent library) I would argue is grounds for a minor version bump. Since the API that log4j provides does not change in any of these circumstances, there is no need to bump the major version(although you could if you want, I suppose). The examples I gave before are when you must increment the version number(according to my understanding) - I don't see any issue in increasing the version number when you are not in one of those scenarios. For example, the Linux kernel has a somewhat arbitrary major number, since it doesn't really tell you what API the kernel has(there is no stable interface inside of the kernel). -Robert Middleton
