Hi Volkan, On Mon, 11 Dec 2023 at 10:26, Volkan Yazıcı <vol...@yazi.ci> wrote: > *Given a version number `MAJOR.MINOR.PATCH`, increment the:* > > > - *MAJOR version when you make incompatible API changes* > - *MINOR version when you add functionality in a backward compatible > manner* > - *PATCH version when you make backward compatible bug fixes* > > I think we all agree on what warrants a major version bump. The definition > of what constitutes an API, etc. are all open to interpretation, but we > have a common sense of it in the PMC.
I think we can split this into a: * minimal version dump, dictated by technical reasons (changes in the methods exposed to the public), * and a component that can not be automatically detected, which is due to change of behavior. E.g. I can modify the behavior of the `%i` converter without touching the public API. > We mostly have a problem whether the next release needs a minor or patch > version bump. I propose to refine the official semantics as follows: > > Are we making a release to *only* address a set of particular issues? That > is, does the following hold? > > [next release] = [last release] + [fix1] + [fix2] + ... + [fixN] > > If so, this needs a patch version bump. Otherwise, this is a minor version > bump. What I am having a problem with is the default type of change: * 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. 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. On the other hand if we consider that the `bnd:jar` execution disappeared from `logging-parent`, this might be considered a major version change. Piotr
