I agree with Ralph's view. It is not just the *view* in itself that I find appealing, but the (practically) deterministic nature of it. If one would closely look at Robert's and/or Piotr's explanation of patch-vs-minor strategy, it is pretty subjective, which is exactly the variable I am aiming to eliminate. OTOH, Ralph's (or mine) is pretty straight forward:
Will the next release *only* contain deprecations and/or bug fixes? Then it is a patch release. For all other cases, it is a minor release. [Assuming we all know and agree on what necessitates a major release.] I propose sticking to this versioning scheme for all Logging Services releases and documenting it. Objections? [Or, if I may say,] strong objections? 😅 On Mon, Dec 11, 2023 at 10:44 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > The rule for this seems extremely simple to me. The changelog uses > > <simpleType name="changeType”> > <restriction base="string”> > <enumeration value="added”/> > <enumeration value="changed”/> > <enumeration value="deprecated”/> > <enumeration value="removed”/> > <enumeration value="fixed”/> > </restriction> > </simpleType> > > If every entry is deprecated or fixed it is a patch release. Everything > else is a minor release. Yes, I realize that you can add, change or remove > things without impacting compatibility but whether it is a patch or minor > release isn’t about compatibility. > > Ralph > > > On Dec 11, 2023, at 1:43 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > 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 > >> > >
