IMO: A new protected or public anything needs a minor version bump. I think that follows sem ver.
Gary On Mon, Dec 11, 2023, 1:56 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > 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 >
