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 <[email protected]> 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 <[email protected]>
> wrote:
>
>> Hi Volkan,
>>
>> On Mon, 11 Dec 2023 at 10:26, Volkan Yazıcı <[email protected]> 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
>>
