On Mon, Dec 11, 2023 at 7:56 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote:
> * for me every release should be a **patch** release, unless there > are reasons to publish a minor release. For example the next Log4j release should be 2.22.1. This is the old strategy used by Log4j; > * recently this strategy shifted to: every release is a **minor** > release, unless someone justifies that it can be a patch release. All > our repos are currently using a snapshot version that is a minor > version bump from the previous release. > > In the end the result (release version number) might be the same, but > the burden of proof falls on those advocating for a patch release. > I don't understand what you mean by "the burden of proof falls on those advocating for a patch release". Could you elaborate on it, please? > The concrete example of `logging-parent` is hard to discuss, since it > is not written in Java, but a mix of Maven plugins, bash scripts and > Github action workflows. Your fix of the problem we were having with > `META-INF/services/` is pretty nice, but for me it constitutes a bug > fix, not a new feature children project can rely upon. The value of > the contribution does not depend on the version bump it generates, > patch contributions require usually more effort. > The recent `logging-parent` release increases the compiler baseline from Java 8 to Java 17 due to the upgrade of BND from version `6.x` to `7.0.0`, which requires Java 17. Plus, `bnd:jar` is switched to `bnd:bnd-process` – a backward compatible behaviour change. Though nothing urgent, a good-to-have. Plus, several dependencies are upgraded – again, nothing urgent, a good-to-have. In conclusion, we have a JDK baseline bump along with not-urgent-but-good-to-have backward compatible changes. I think these are too big and too optional to be shipped in a patch release. As this conversation shows one more time, my main argument is against a rule that is too open to interpretation. I prefer to have a rule that has practically no room for ambiguity and at the same time makes sense in the semver framework. For the record, do you have a clear definition of your proposal? *"Every release should be a patch release"* doesn't really help.
