Re: [log4j-kotlin] Next release (`1.3.1`-vs-`1.4.0`)

[Volkan Yazıcı]

Thanks for the prompt action. 🙏
I will review the PR.

Please keep in mind that you don't have sufficient rights to complete a
release. A PMC member should volunteer as an RM (Release Manager), who, in
your case, is Matt, I presume. That is, you can perform the git chores, but
it is Matt who should do the rest of the release instructions
.

On Mon, Dec 11, 2023 at 11:53 PM Raman Gupta  wrote:

> Thanks for the feedback Volkan. The PR with all of these changes is:
>
> https://github.com/apache/logging-log4j-kotlin/pull/56
>
> Regards,
> Raman
>
> On Thu, Dec 7, 2023 at 5:54 AM Volkan Yazıcı  wrote:
>
>> Raman, Matt, great that you want to release the next version of the Log4j
>> Kotlin! Thanks for your time and effort.
>>
>> I see that you forked the `release/1.3.1` branch from the `rel/1.3.0`
>> tag, though this misses some minor, but important  changes (e.g., SBOM &
>> VDR!) from `main`. I suggest we fork from `main` and release `1.4.0`
>> instead.
>>
>
> Done
>
>
>> There are some chores that have been waiting for the next release to be
>> performed. I will share them below and appreciate it if you can carry them
>> out.
>>
>> *Add `project.build.outputTimestamp` Maven property*
>>
>> Please copy this property (incl. the large comment block preceding it!)
>> from the `2.x` branch of the `logging-log4j2` repository and incorporate it
>> into `/pom.xml` of `log4j-kotlin`. Try to place it exactly at the same
>> location: right after `revision`.
>>
>> I might sound pedantic about this and I am. I try really hard to make all
>> `pom.xml`s look alike to avoid the surprise factor maintainers suffer from
>> while jumping from one project to another. Not to mention this also helps
>> us to carry out automation, e.g., `project.build.outputTimestamp` is
>> replaced by `logging-parent` CI magic during release.
>>
>>
> Done
>
>
>> *Remove `cyclonedx-maven-plugin` override*
>>
>> Remove the `cyclonedx-maven-plugin` override (and the comment block
>> preceding it) from `/pom.xml`. This is not necessary anymore with the
>> `logging-parent` version `0.4.0` release.
>>
>
> Done
>
>
>>
>> *Changelog cleanup*
>>
>> Make sure `src/changelog/.1.x.x` contents look good. You can verify this
>> by skimming through `src/site` after issuing a `./mvnw process-sources`.
>>
>> Could you update all changelog XSDs to version `0.1.2` too, please?
>>
>> I would also appreciate it if you can remove all `author` elements from
>> `src/changelog/*/*.xml` files. They are neither rendered by the template,
>> nor provide information that one cannot obtain from the associated
>> commit/ticket.
>>
>
> Done
>
>
>>
>> *Generated emails*
>>
>> Please don't send generated emails verbatim! Nexus URLs need to be
>> manually filled in and there are always some minor formatting details to
>> fix in the text.
>>
>
> Will keep this in mind.
>
> Thanks,
> Raman
>
>

Re: Versioning scheme

[Volkan Yazıcı]

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 
wrote:

> The rule for this seems extremely simple to me.  The changelog uses
>
> 
> 
> 
> 

Re: Versioning scheme

[Piotr P. Karwasz]

Hi Ralph,

On Mon, 11 Dec 2023 at 22:43, Ralph Goers  wrote:
>
> The rule for this seems extremely simple to me.  The changelog uses
>
> 
> 
> 
> 

Re: Versioning scheme

[Volkan Yazıcı]

On Tue, Dec 12, 2023 at 11:47 AM Piotr P. Karwasz 
wrote:

>  * we lack a way to classify dependency updates. A concrete example:
> did the Commons DBCP2 bump to 2.11.0 change anything in
> `log4j-jdbc-dbcp2`? I don't think so, the artifact compiles with
> version 2.2.0 of the artifact. We are only stating that
> `log4j-jdbc-dbcp2` will **also** work with version 2.11.0.
>

Exactly! Hence, it is clear that this is neither a bug fix, nor a
deprecation. That is, there is no ambiguity that this goes into a minor
release.


> I don't think this warrants a minor version bump.
>

This is what I am trying to eliminate Piotr: opinions. When a person starts
thinking *"Shall this be a patch or minor release?"*, the outcome is
inherently subjective. We cannot completely get rid of subjective
assessment, but assist it with guardrails.


>  * we lack a type to classify internal changes to the build system.
> The bump to JDK 17 was necessary, very useful for us, but users don't
> really care what JDK was used for compilation.


What? Users, that is, developers using `logging-parent` as their parent
project, do certainly care about this change. Why wouldn't they? This is
*not* a simple change. It took us months to bump the compiler in Log4j. I
think your statement has an incorrect assumption on who the users of
`logging-parent` are.


> Lacking a special "upgraded" type I would classify those changes as
> "fixed", hence a patch level change.
>

I have the impression that you want to classify library updates that don't
disrupt the user experience as a patch release. If there is nothing urgent
about them, why do a patch release at all? Isn't the point of a patch
release is to fix something, urgently? Piggybacking library updates into
patch releases defeats the purpose of patch releases and makes the line
between minor and patch releases blur, and that is the crux of our
disagreement.

Re: Versioning scheme

[Piotr P. Karwasz]

Hi Volkan,

On Tue, 12 Dec 2023 at 13:02, Volkan Yazıcı  wrote:
>
> On Tue, Dec 12, 2023 at 11:47 AM Piotr P. Karwasz 
> wrote:
>
> >  * we lack a way to classify dependency updates. A concrete example:
> > did the Commons DBCP2 bump to 2.11.0 change anything in
> > `log4j-jdbc-dbcp2`? I don't think so, the artifact compiles with
> > version 2.2.0 of the artifact. We are only stating that
> > `log4j-jdbc-dbcp2` will **also** work with version 2.11.0.
> >
>
> Exactly! Hence, it is clear that this is neither a bug fix, nor a
> deprecation. That is, there is no ambiguity that this goes into a minor
> release.

And here I don't agree. Dependabot upgrades provide **no** benefit to
the generated JAR files. Even the bytecode is exactly the same as
before the upgrade.

What these changes provide is part of our "Secure by default" or
"Up-to-date by default" feature: Log4j artifacts will never freeze our
clients dependencies and will work with the newest versions of the
libraries we depend upon.

If you need to **manually** fix code for the upgrade to work (as you
did for Jackson 2.16.0), then you can change the automatically
generated entry from "fixed/upgraded" to "changed".

> > I don't think this warrants a minor version bump.
> >
>
> This is what I am trying to eliminate Piotr: opinions. When a person starts
> thinking *"Shall this be a patch or minor release?"*, the outcome is
> inherently subjective. We cannot completely get rid of subjective
> assessment, but assist it with guardrails.

These guardrails seem to follow the easy path: let's just do minor
releases, so nobody will tell us we are wrong. If you add ".0.0" to
all Google Chrome versions, Chrome will also follow semver to the
letter. It just loses the spirit.

> > The bump to JDK 17 was necessary, very useful for us, but users don't
> > really care what JDK was used for compilation.
>
>
> What? Users, that is, developers using `logging-parent` as their parent
> project, do certainly care about this change. Why wouldn't they? This is
> *not* a simple change. It took us months to bump the compiler in Log4j. I
> think your statement has an incorrect assumption on who the users of
> `logging-parent` are.

Sorry, I was still talking about Log4j. For `logging-parent` users the
requirement to use JDK 17 is a minor change, but `log4j-core` users do
not care what JDK we are using for compilation. Therefore the switch
to JDK 17 for compilation is not reason enough to bump Log4j to
2.23.0.

> I have the impression that you want to classify library updates that don't
> disrupt the user experience as a patch release. If there is nothing urgent
> about them, why do a patch release at all? Isn't the point of a patch
> release is to fix something, urgently? Piggybacking library updates into
> patch releases defeats the purpose of patch releases and makes the line
> between minor and patch releases blur, and that is the crux of our
> disagreement.

I would do a release at all if it only contains changes in the
dependency versions. The only exception I would make is vulnerable
dependencies, **if** we are affected by the vulnerability. If this is
the case feel free to replace "fixed/upgraded" with "changed" in the
changelog.

In case a dependency upgrade does not influence the bytecode (i.e. our
artifacts still work with the old version), I would simply disregard
the upgrade when computing the required version dump.

Piotr

Re: Versioning scheme

[Christian Grobmeier]

On Tue, Dec 12, 2023, at 09:43, Volkan Yazıcı wrote:
> 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, 

I don't think Roberts's view was subjective; he gave some clear rules to follow.

> 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.]

Well, this is what is said here, right?

- *MINOR version when you add functionality in a backward compatible manner*
- *PATCH version when you make backward compatible bug fixes*

Deprecations are no change in functionality but only a @deprecated tag. I 
assume this is why
they are not listed specifically, and also don't see the need for it.

> I propose sticking to this versioning scheme for all Logging Services
> releases and documenting it. Objections? 

I am okay with following semver, as we already did. 

I am against re-documenting what is already documented in semver. We can 
mention that we use semver, but please don't write documents that interpret 
semver further.

Are we trying to solve an actual problem? I have not seen a disagreement on a 
previous version number yet, or did I miss it in the flood of emails?

Christian

Re: Versioning scheme

[Ralph Goers]

I have to agree with Piotr’s example. Simply upgrading a dependency doesn’t, on 
its own, change any code in Log4j.

I see three possible solutions for this:

1. Do not allow any dependency updates until a “scheduled” mentor release (once 
every 2 or 3 months). Frankly I’d be fine with this except when a dependency 
has a major security vulnerability.
2. Change all dependency versions to be ranges such that they don’t require a 
release for users to include new dependency releases.  (I cannot really 
recommend doing this).
3. Add a new type to represent dependency updates. This would also not require 
a minor release. This is really the most appropriate fix as updating a 
dependency is not a change to anything in Log4j. 

I would suggest adding another enumeration named “update”.

Ralph

> On Dec 12, 2023, at 7:19 AM, Piotr P. Karwasz  wrote:
> 
> Hi Volkan,
> 
> On Tue, 12 Dec 2023 at 13:02, Volkan Yazıcı  > wrote:
>> 
>> On Tue, Dec 12, 2023 at 11:47 AM Piotr P. Karwasz 
>> wrote:
>> 
>>> * we lack a way to classify dependency updates. A concrete example:
>>> did the Commons DBCP2 bump to 2.11.0 change anything in
>>> `log4j-jdbc-dbcp2`? I don't think so, the artifact compiles with
>>> version 2.2.0 of the artifact. We are only stating that
>>> `log4j-jdbc-dbcp2` will **also** work with version 2.11.0.
>>> 
>> 
>> Exactly! Hence, it is clear that this is neither a bug fix, nor a
>> deprecation. That is, there is no ambiguity that this goes into a minor
>> release.
> 
> And here I don't agree. Dependabot upgrades provide **no** benefit to
> the generated JAR files. Even the bytecode is exactly the same as
> before the upgrade.
> 
> What these changes provide is part of our "Secure by default" or
> "Up-to-date by default" feature: Log4j artifacts will never freeze our
> clients dependencies and will work with the newest versions of the
> libraries we depend upon.
> 
> If you need to **manually** fix code for the upgrade to work (as you
> did for Jackson 2.16.0), then you can change the automatically
> generated entry from "fixed/upgraded" to "changed".
> 
>>> I don't think this warrants a minor version bump.
>>> 
>> 
>> This is what I am trying to eliminate Piotr: opinions. When a person starts
>> thinking *"Shall this be a patch or minor release?"*, the outcome is
>> inherently subjective. We cannot completely get rid of subjective
>> assessment, but assist it with guardrails.
> 
> These guardrails seem to follow the easy path: let's just do minor
> releases, so nobody will tell us we are wrong. If you add ".0.0" to
> all Google Chrome versions, Chrome will also follow semver to the
> letter. It just loses the spirit.
> 
>>> The bump to JDK 17 was necessary, very useful for us, but users don't
>>> really care what JDK was used for compilation.
>> 
>> 
>> What? Users, that is, developers using `logging-parent` as their parent
>> project, do certainly care about this change. Why wouldn't they? This is
>> *not* a simple change. It took us months to bump the compiler in Log4j. I
>> think your statement has an incorrect assumption on who the users of
>> `logging-parent` are.
> 
> Sorry, I was still talking about Log4j. For `logging-parent` users the
> requirement to use JDK 17 is a minor change, but `log4j-core` users do
> not care what JDK we are using for compilation. Therefore the switch
> to JDK 17 for compilation is not reason enough to bump Log4j to
> 2.23.0.
> 
>> I have the impression that you want to classify library updates that don't
>> disrupt the user experience as a patch release. If there is nothing urgent
>> about them, why do a patch release at all? Isn't the point of a patch
>> release is to fix something, urgently? Piggybacking library updates into
>> patch releases defeats the purpose of patch releases and makes the line
>> between minor and patch releases blur, and that is the crux of our
>> disagreement.
> 
> I would do a release at all if it only contains changes in the
> dependency versions. The only exception I would make is vulnerable
> dependencies, **if** we are affected by the vulnerability. If this is
> the case feel free to replace "fixed/upgraded" with "changed" in the
> changelog.
> 
> In case a dependency upgrade does not influence the bytecode (i.e. our
> artifacts still work with the old version), I would simply disregard
> the upgrade when computing the required version dump.
> 
> Piotr

Re: Versioning scheme

[Ralph Goers]

> On Dec 11, 2023, at 2:32 PM, Piotr P. Karwasz  wrote:
> 
> I propose to keep the old strategy: after a release we set the version
> number to the next patch release.
> Only if we merge a change that requires a minor bump (we can tag
> those), we bump the release to the next minor version.

Actually, the strategy was to always make the version number a patch release. 
It really didn’t matter what the version number was though. When I ran the 
release plugin I always specified the release version so all the pom versions 
got updated regardless of what they were.

I would prefer that the CI system determine the release number based on what is 
in the changelog. That simply means we need to have enough enumerations to 
handle all the cases and be able to classify each enumeration as either patch 
or minor.

Ralph

Re: Versioning scheme

[Volkan Yazıcı]

Piotr, could you give me a well-defined formula of your desired versioning
scheme concerning minor/patch bumps?

On Tue, 12 Dec 2023 at 15:19, Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Tue, 12 Dec 2023 at 13:02, Volkan Yazıcı  wrote:
> >
> > On Tue, Dec 12, 2023 at 11:47 AM Piotr P. Karwasz <
> piotr.karw...@gmail.com>
> > wrote:
> >
> > >  * we lack a way to classify dependency updates. A concrete example:
> > > did the Commons DBCP2 bump to 2.11.0 change anything in
> > > `log4j-jdbc-dbcp2`? I don't think so, the artifact compiles with
> > > version 2.2.0 of the artifact. We are only stating that
> > > `log4j-jdbc-dbcp2` will **also** work with version 2.11.0.
> > >
> >
> > Exactly! Hence, it is clear that this is neither a bug fix, nor a
> > deprecation. That is, there is no ambiguity that this goes into a minor
> > release.
>
> And here I don't agree. Dependabot upgrades provide **no** benefit to
> the generated JAR files. Even the bytecode is exactly the same as
> before the upgrade.
>
> What these changes provide is part of our "Secure by default" or
> "Up-to-date by default" feature: Log4j artifacts will never freeze our
> clients dependencies and will work with the newest versions of the
> libraries we depend upon.
>
> If you need to **manually** fix code for the upgrade to work (as you
> did for Jackson 2.16.0), then you can change the automatically
> generated entry from "fixed/upgraded" to "changed".
>
> > > I don't think this warrants a minor version bump.
> > >
> >
> > This is what I am trying to eliminate Piotr: opinions. When a person
> starts
> > thinking *"Shall this be a patch or minor release?"*, the outcome is
> > inherently subjective. We cannot completely get rid of subjective
> > assessment, but assist it with guardrails.
>
> These guardrails seem to follow the easy path: let's just do minor
> releases, so nobody will tell us we are wrong. If you add ".0.0" to
> all Google Chrome versions, Chrome will also follow semver to the
> letter. It just loses the spirit.
>
> > > The bump to JDK 17 was necessary, very useful for us, but users don't
> > > really care what JDK was used for compilation.
> >
> >
> > What? Users, that is, developers using `logging-parent` as their parent
> > project, do certainly care about this change. Why wouldn't they? This is
> > *not* a simple change. It took us months to bump the compiler in Log4j. I
> > think your statement has an incorrect assumption on who the users of
> > `logging-parent` are.
>
> Sorry, I was still talking about Log4j. For `logging-parent` users the
> requirement to use JDK 17 is a minor change, but `log4j-core` users do
> not care what JDK we are using for compilation. Therefore the switch
> to JDK 17 for compilation is not reason enough to bump Log4j to
> 2.23.0.
>
> > I have the impression that you want to classify library updates that
> don't
> > disrupt the user experience as a patch release. If there is nothing
> urgent
> > about them, why do a patch release at all? Isn't the point of a patch
> > release is to fix something, urgently? Piggybacking library updates into
> > patch releases defeats the purpose of patch releases and makes the line
> > between minor and patch releases blur, and that is the crux of our
> > disagreement.
>
> I would do a release at all if it only contains changes in the
> dependency versions. The only exception I would make is vulnerable
> dependencies, **if** we are affected by the vulnerability. If this is
> the case feel free to replace "fixed/upgraded" with "changed" in the
> changelog.
>
> In case a dependency upgrade does not influence the bytecode (i.e. our
> artifacts still work with the old version), I would simply disregard
> the upgrade when computing the required version dump.
>
> Piotr
>

Re: Versioning scheme

[Volkan Yazıcı]

Ralph, do you mean if all changes are a subset of bug fixes, deprecations,
or updates, then it is a patch release?

On Tue, 12 Dec 2023 at 16:23, Ralph Goers 
wrote:

> I have to agree with Piotr’s example. Simply upgrading a dependency
> doesn’t, on its own, change any code in Log4j.
>
> I see three possible solutions for this:
>
> 1. Do not allow any dependency updates until a “scheduled” mentor release
> (once every 2 or 3 months). Frankly I’d be fine with this except when a
> dependency has a major security vulnerability.
> 2. Change all dependency versions to be ranges such that they don’t
> require a release for users to include new dependency releases.  (I cannot
> really recommend doing this).
> 3. Add a new type to represent dependency updates. This would also not
> require a minor release. This is really the most appropriate fix as
> updating a dependency is not a change to anything in Log4j.
>
> I would suggest adding another enumeration named “update”.
>
> Ralph
>
> > On Dec 12, 2023, at 7:19 AM, Piotr P. Karwasz 
> wrote:
> >
> > Hi Volkan,
> >
> > On Tue, 12 Dec 2023 at 13:02, Volkan Yazıcı  vol...@yazi.ci>> wrote:
> >>
> >> On Tue, Dec 12, 2023 at 11:47 AM Piotr P. Karwasz <
> piotr.karw...@gmail.com>
> >> wrote:
> >>
> >>> * we lack a way to classify dependency updates. A concrete example:
> >>> did the Commons DBCP2 bump to 2.11.0 change anything in
> >>> `log4j-jdbc-dbcp2`? I don't think so, the artifact compiles with
> >>> version 2.2.0 of the artifact. We are only stating that
> >>> `log4j-jdbc-dbcp2` will **also** work with version 2.11.0.
> >>>
> >>
> >> Exactly! Hence, it is clear that this is neither a bug fix, nor a
> >> deprecation. That is, there is no ambiguity that this goes into a minor
> >> release.
> >
> > And here I don't agree. Dependabot upgrades provide **no** benefit to
> > the generated JAR files. Even the bytecode is exactly the same as
> > before the upgrade.
> >
> > What these changes provide is part of our "Secure by default" or
> > "Up-to-date by default" feature: Log4j artifacts will never freeze our
> > clients dependencies and will work with the newest versions of the
> > libraries we depend upon.
> >
> > If you need to **manually** fix code for the upgrade to work (as you
> > did for Jackson 2.16.0), then you can change the automatically
> > generated entry from "fixed/upgraded" to "changed".
> >
> >>> I don't think this warrants a minor version bump.
> >>>
> >>
> >> This is what I am trying to eliminate Piotr: opinions. When a person
> starts
> >> thinking *"Shall this be a patch or minor release?"*, the outcome is
> >> inherently subjective. We cannot completely get rid of subjective
> >> assessment, but assist it with guardrails.
> >
> > These guardrails seem to follow the easy path: let's just do minor
> > releases, so nobody will tell us we are wrong. If you add ".0.0" to
> > all Google Chrome versions, Chrome will also follow semver to the
> > letter. It just loses the spirit.
> >
> >>> The bump to JDK 17 was necessary, very useful for us, but users don't
> >>> really care what JDK was used for compilation.
> >>
> >>
> >> What? Users, that is, developers using `logging-parent` as their parent
> >> project, do certainly care about this change. Why wouldn't they? This is
> >> *not* a simple change. It took us months to bump the compiler in Log4j.
> I
> >> think your statement has an incorrect assumption on who the users of
> >> `logging-parent` are.
> >
> > Sorry, I was still talking about Log4j. For `logging-parent` users the
> > requirement to use JDK 17 is a minor change, but `log4j-core` users do
> > not care what JDK we are using for compilation. Therefore the switch
> > to JDK 17 for compilation is not reason enough to bump Log4j to
> > 2.23.0.
> >
> >> I have the impression that you want to classify library updates that
> don't
> >> disrupt the user experience as a patch release. If there is nothing
> urgent
> >> about them, why do a patch release at all? Isn't the point of a patch
> >> release is to fix something, urgently? Piggybacking library updates into
> >> patch releases defeats the purpose of patch releases and makes the line
> >> between minor and patch releases blur, and that is the crux of our
> >> disagreement.
> >
> > I would do a release at all if it only contains changes in the
> > dependency versions. The only exception I would make is vulnerable
> > dependencies, **if** we are affected by the vulnerability. If this is
> > the case feel free to replace "fixed/upgraded" with "changed" in the
> > changelog.
> >
> > In case a dependency upgrade does not influence the bytecode (i.e. our
> > artifacts still work with the old version), I would simply disregard
> > the upgrade when computing the required version dump.
> >
> > Piotr
>
>

Re: Versioning scheme

[Ralph Goers]

Yes.

Ralph

> On Dec 12, 2023, at 9:03 AM, Volkan Yazıcı  wrote:
> 
> Ralph, do you mean if all changes are a subset of bug fixes, deprecations,
> or updates, then it is a patch release?
> 
> On Tue, 12 Dec 2023 at 16:23, Ralph Goers 
> wrote:
> 
>> I have to agree with Piotr’s example. Simply upgrading a dependency
>> doesn’t, on its own, change any code in Log4j.
>> 
>> I see three possible solutions for this:
>> 
>> 1. Do not allow any dependency updates until a “scheduled” mentor release
>> (once every 2 or 3 months). Frankly I’d be fine with this except when a
>> dependency has a major security vulnerability.
>> 2. Change all dependency versions to be ranges such that they don’t
>> require a release for users to include new dependency releases.  (I cannot
>> really recommend doing this).
>> 3. Add a new type to represent dependency updates. This would also not
>> require a minor release. This is really the most appropriate fix as
>> updating a dependency is not a change to anything in Log4j.
>> 
>> I would suggest adding another enumeration named “update”.
>> 
>> Ralph
>> 
>>> On Dec 12, 2023, at 7:19 AM, Piotr P. Karwasz 
>> wrote:
>>> 
>>> Hi Volkan,
>>> 
>>> On Tue, 12 Dec 2023 at 13:02, Volkan Yazıcı > vol...@yazi.ci>> wrote:
 
 On Tue, Dec 12, 2023 at 11:47 AM Piotr P. Karwasz <
>> piotr.karw...@gmail.com>
 wrote:
 
> * we lack a way to classify dependency updates. A concrete example:
> did the Commons DBCP2 bump to 2.11.0 change anything in
> `log4j-jdbc-dbcp2`? I don't think so, the artifact compiles with
> version 2.2.0 of the artifact. We are only stating that
> `log4j-jdbc-dbcp2` will **also** work with version 2.11.0.
> 
 
 Exactly! Hence, it is clear that this is neither a bug fix, nor a
 deprecation. That is, there is no ambiguity that this goes into a minor
 release.
>>> 
>>> And here I don't agree. Dependabot upgrades provide **no** benefit to
>>> the generated JAR files. Even the bytecode is exactly the same as
>>> before the upgrade.
>>> 
>>> What these changes provide is part of our "Secure by default" or
>>> "Up-to-date by default" feature: Log4j artifacts will never freeze our
>>> clients dependencies and will work with the newest versions of the
>>> libraries we depend upon.
>>> 
>>> If you need to **manually** fix code for the upgrade to work (as you
>>> did for Jackson 2.16.0), then you can change the automatically
>>> generated entry from "fixed/upgraded" to "changed".
>>> 
> I don't think this warrants a minor version bump.
> 
 
 This is what I am trying to eliminate Piotr: opinions. When a person
>> starts
 thinking *"Shall this be a patch or minor release?"*, the outcome is
 inherently subjective. We cannot completely get rid of subjective
 assessment, but assist it with guardrails.
>>> 
>>> These guardrails seem to follow the easy path: let's just do minor
>>> releases, so nobody will tell us we are wrong. If you add ".0.0" to
>>> all Google Chrome versions, Chrome will also follow semver to the
>>> letter. It just loses the spirit.
>>> 
> The bump to JDK 17 was necessary, very useful for us, but users don't
> really care what JDK was used for compilation.
 
 
 What? Users, that is, developers using `logging-parent` as their parent
 project, do certainly care about this change. Why wouldn't they? This is
 *not* a simple change. It took us months to bump the compiler in Log4j.
>> I
 think your statement has an incorrect assumption on who the users of
 `logging-parent` are.
>>> 
>>> Sorry, I was still talking about Log4j. For `logging-parent` users the
>>> requirement to use JDK 17 is a minor change, but `log4j-core` users do
>>> not care what JDK we are using for compilation. Therefore the switch
>>> to JDK 17 for compilation is not reason enough to bump Log4j to
>>> 2.23.0.
>>> 
 I have the impression that you want to classify library updates that
>> don't
 disrupt the user experience as a patch release. If there is nothing
>> urgent
 about them, why do a patch release at all? Isn't the point of a patch
 release is to fix something, urgently? Piggybacking library updates into
 patch releases defeats the purpose of patch releases and makes the line
 between minor and patch releases blur, and that is the crux of our
 disagreement.
>>> 
>>> I would do a release at all if it only contains changes in the
>>> dependency versions. The only exception I would make is vulnerable
>>> dependencies, **if** we are affected by the vulnerability. If this is
>>> the case feel free to replace "fixed/upgraded" with "changed" in the
>>> changelog.
>>> 
>>> In case a dependency upgrade does not influence the bytecode (i.e. our
>>> artifacts still work with the old version), I would simply disregard
>>> the upgrade when computing the required version dump.
>>> 
>>> Piotr
>> 
>> 

Re: Versioning scheme

[Piotr P. Karwasz]

Hi Volkan,

On Tue, 12 Dec 2023 at 17:00, Volkan Yazıcı  wrote:
> Piotr, could you give me a well-defined formula of your desired versioning
> scheme concerning minor/patch bumps?

I agree with what Ralph proposed.

What I don't agree with is the current practice to set up the **next**
release version always to the next minor release (with an empty set of
changes).
I would set it to the next patch release and only transform it into a
minor release if we add an `added` or `changed` changelog entry.
As Ralph said, the CI could do it.

Piotr

Re: Versioning scheme

[Volkan Yazıcı]

Got it. I will land a log4j-changelog change accordingly, implement the CI
magic, and update the release instructions.

On Tue, 12 Dec 2023 at 17:41, Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Tue, 12 Dec 2023 at 17:00, Volkan Yazıcı  wrote:
> > Piotr, could you give me a well-defined formula of your desired
> versioning
> > scheme concerning minor/patch bumps?
>
> I agree with what Ralph proposed.
>
> What I don't agree with is the current practice to set up the **next**
> release version always to the next minor release (with an empty set of
> changes).
> I would set it to the next patch release and only transform it into a
> minor release if we add an `added` or `changed` changelog entry.
> As Ralph said, the CI could do it.
>
> Piotr
>

Re: Versioning scheme

[Ralph Goers]

Maybe you could add comments to the schema to define what the enumerations are 
intended for and what effect they have on the release?

Ralph

> On Dec 12, 2023, at 10:13 AM, Volkan Yazıcı  wrote:
> 
> Got it. I will land a log4j-changelog change accordingly, implement the CI
> magic, and update the release instructions.
> 
> On Tue, 12 Dec 2023 at 17:41, Piotr P. Karwasz 
> wrote:
> 
>> Hi Volkan,
>> 
>> On Tue, 12 Dec 2023 at 17:00, Volkan Yazıcı  wrote:
>>> Piotr, could you give me a well-defined formula of your desired
>> versioning
>>> scheme concerning minor/patch bumps?
>> 
>> I agree with what Ralph proposed.
>> 
>> What I don't agree with is the current practice to set up the **next**
>> release version always to the next minor release (with an empty set of
>> changes).
>> I would set it to the next patch release and only transform it into a
>> minor release if we add an `added` or `changed` changelog entry.
>> As Ralph said, the CI could do it.
>> 
>> Piotr
>> 

Re: Versioning scheme

[Volkan Yazıcı]

Interesting. Could you share a concrete example, please?

On Tue, Dec 12, 2023 at 8:16 PM Ralph Goers 
wrote:

> Maybe you could add comments to the schema to define what the enumerations
> are intended for and what effect they have on the release?
>
> Ralph
>
> > On Dec 12, 2023, at 10:13 AM, Volkan Yazıcı  wrote:
> >
> > Got it. I will land a log4j-changelog change accordingly, implement the
> CI
> > magic, and update the release instructions.
> >
> > On Tue, 12 Dec 2023 at 17:41, Piotr P. Karwasz 
> > wrote:
> >
> >> Hi Volkan,
> >>
> >> On Tue, 12 Dec 2023 at 17:00, Volkan Yazıcı  wrote:
> >>> Piotr, could you give me a well-defined formula of your desired
> >> versioning
> >>> scheme concerning minor/patch bumps?
> >>
> >> I agree with what Ralph proposed.
> >>
> >> What I don't agree with is the current practice to set up the **next**
> >> release version always to the next minor release (with an empty set of
> >> changes).
> >> I would set it to the next patch release and only transform it into a
> >> minor release if we add an `added` or `changed` changelog entry.
> >> As Ralph said, the CI could do it.
> >>
> >> Piotr
> >>
>
>