Re: Versioning scheme

[Robert Middleton]

This is going to be somewhat subjective and may be on a case-by-case
basis, but here are my thoughts:

On Mon, Dec 11, 2023 at 2:17 PM Volkan Yazıcı  wrote:
>
> I think this is where we have different ideas.
> Robert, could you elaborate on *"change/fix behavior without adding new
> method"*, please? For instance, does this cover the following changes?
>
>- Upgrading a dependency whose patch version is bumped (no behavior
>change on the parts we use the dependency)
>- Upgrading a dependency whose minor version is bumped (no behavior
>change on the parts we use the dependency)
>- Upgrading a dependency whose major version is bumped (no behavior
>change on the parts we use the dependency)
>- Upgrading a dependency whose major version is bumped (no behavior
>change on the parts we use the dependency, though the runtime requirements
>of the dependency has changed, e.g., started requiring Java 17 instead of
>Java 8, etc.)
>- `sum(a,b)` has changed from `a+b` to `a-b` (behaviour change, no new
>method)
>- `sum(a,b)` has started using GPUs (no change visible to the user,
>though substantial implementation change)
>

I think all of these would be either a patch/minor version change -
semver is showing users of your library(in this case log4j) what YOU
provide, not what you depend on.  The more difficult/large the change
is(using GPU, bumping a dependent library) I would argue is grounds
for a minor version bump.  Since the API that log4j provides does not
change in any of these circumstances, there is no need to bump the
major version(although you could if you want, I suppose).

The examples I gave before are when you must increment the version
number(according to my understanding) - I don't see any issue in
increasing the version number when you are not in one of those
scenarios.  For example, the Linux kernel has a somewhat arbitrary
major number, since it doesn't really tell you what API the kernel
has(there is no stable interface inside of the kernel).

-Robert Middleton

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

[Raman Gupta]

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

[Ralph Goers]

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

Re: Versioning scheme

[Piotr P. Karwasz]

On Mon, 11 Dec 2023 at 20:33, Volkan Yazıcı  wrote:
> > 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.
> >
>
> I don't understand what you mean by "the burden of proof falls on those
> advocating for a patch release". Could you elaborate on it, please?

If you were to release Log4j right now from `2.x` what version would
you use? Almost certainly 2.23.0, since:

 * the current snapshot version is 2.23.0-SNAPSHOT,
 * there is a 2.23.0 milestone:
https://github.com/apache/logging-log4j2/milestone/9

The fact that the milestone contains only two patch-level changes is
completely hidden. Either the Release Manager or the PMC members
checking the release would have to go through those issues and prove
that it is a 2.22.1 release.

> As this conversation shows one more time, my main argument is against a
> rule that is too open to interpretation. I prefer to have a rule that has
> practically no room for ambiguity and at the same time makes sense in the
> semver framework.

Ambiguity is natural in the context of semver. We are supposed to
convey a meaning, so we should try to categorize each change properly
and discuss the changes hard to classify.

There is a simple case: if BND says MINOR change, it is usually a
minor change. However a change can always be upgraded due to reasons
besides the public API changes.

Regarding the classification of changes I also tend to look at our doc:

 * if the previous behavior disagreed with the doc, correcting it is a
bug fix (we probably all agree),
 * if we change a previously documented behavior, it is a minor bump
(here we also probably agree),
 * if we change a behavior that was **not** documented (e.g. the
evaluation of lookups in user data ;-), we should discuss about it.

> For the record, do you have a clear definition of your proposal? *"Every
> release should be a patch release"* doesn't really help.

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.

Piotr

PS: Of course the examples for Log4j are a little bit artificial,
since Ralph's PR bumped the release number:
https://github.com/apache/logging-log4j2/pull/2062

Re: [Flume] Integration with OpenTelemetry

[Tristan Stevens]

Hi all,
Very supportive of this. I've always thought that Flume is a great alternative 
to fluentd and could easily provide an enhanced capability set (Kafka, Log4J , 
JMS, etc) and simple scale out architecture. Open telemetry native support 
would be great, as would deployment via Kubernetes.

I started work on a Docker build here https://github.com/apache/flume/pull/351 
which could be used as the basis as a Kubernetes deployment and no reason why 
we couldn't follow up with an Operator as well. At the time we lacked any 
committers with enough expertise to validate the approach, and then the maven 
plugin got deprecated, but if there's anyone with the expertise to pick this 
up, I'd be more than happy to support however I can.

Unlocking deployability of Flume is key to its survival IMHO.

Tristan


From: Matt Sicker 
Sent: Friday, December 1, 2023 5:28:14 pm
To: dev@logging.apache.org 
Subject: Re: [Flume] Integration with OpenTelemetry


> On Nov 30, 2023, at 12:13 PM, Christian Grobmeier  
> wrote:
>
> Please do. I would also like to learn more about this stuff and maybe we can 
> make Chainsaw to receive Flume messages or OTel things too!

I think that would make sense. When I do a deeper review of OpenTelemetry, I’ll 
suggest what components here can integrate with what.

Re: Versioning scheme

[Gary Gregory]

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

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

Re: Versioning scheme

[Volkan Yazıcı]

On Mon, Dec 11, 2023 at 7:56 PM Piotr P. Karwasz 
wrote:

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

I don't understand what you mean by "the burden of proof falls on those
advocating for a patch release". Could you elaborate on it, please?


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

The recent `logging-parent` release increases the compiler baseline from
Java 8 to Java 17 due to the upgrade of BND from version `6.x` to `7.0.0`,
which requires Java 17.

Plus, `bnd:jar` is switched to `bnd:bnd-process` – a backward compatible
behaviour change. Though nothing urgent, a good-to-have.

Plus, several dependencies are upgraded – again, nothing urgent, a
good-to-have.

In conclusion, we have a JDK baseline bump along with
not-urgent-but-good-to-have backward compatible changes. I think these are
too big and too optional to be shipped in a patch release.

As this conversation shows one more time, my main argument is against a
rule that is too open to interpretation. I prefer to have a rule that has
practically no room for ambiguity and at the same time makes sense in the
semver framework.

For the record, do you have a clear definition of your proposal? *"Every
release should be a patch release"* doesn't really help.

Re: Versioning scheme

[Volkan Yazıcı]

On Mon, Dec 11, 2023 at 6:20 PM Robert Middleton 
wrote:

> add new method/class = minor version bump
> change/fix behavior without adding new method = patch
>

I think this is where we have different ideas.
Robert, could you elaborate on *"change/fix behavior without adding new
method"*, please? For instance, does this cover the following changes?

   - Upgrading a dependency whose patch version is bumped (no behavior
   change on the parts we use the dependency)
   - Upgrading a dependency whose minor version is bumped (no behavior
   change on the parts we use the dependency)
   - Upgrading a dependency whose major version is bumped (no behavior
   change on the parts we use the dependency)
   - Upgrading a dependency whose major version is bumped (no behavior
   change on the parts we use the dependency, though the runtime requirements
   of the dependency has changed, e.g., started requiring Java 17 instead of
   Java 8, etc.)
   - `sum(a,b)` has changed from `a+b` to `a-b` (behaviour change, no new
   method)
   - `sum(a,b)` has started using GPUs (no change visible to the user,
   though substantial implementation change)

My point is, it is difficult to draw a line and the gray area is pretty
large. Hence, I propose a very simple resolution rule for minor-vs-patch
that doesn't have room for ambiguity: Is it only a selected set of fixes
and nothing else? Then it is a `patch` bump, otherwise everything else is a
`minor` bump.

Re: Versioning scheme

[Volkan Yazıcı]

Yes, we do semver.

No, I am not against alpha, vs.
Though I think we can limit the regex of the `patch` part a bit.

The main problem is that there is no clear line between patch and minor
releases.
[See my response below.]

On Mon, Dec 11, 2023 at 5:15 PM Christian Grobmeier 
wrote:

> I don't understand what is the difference to what semver says.
> When you add functionality, it's a minor. If you just add fixes, it's a
> patch.
> Did I miss something that we are doing differently?
>

I totally agree. Though Piotr doesn't – he better speaks for himself. In a
nutshell, Piotr suggests doing `patch` releases also for *"add
functionality"*, granted it is backward compatible.

Re: Versioning scheme

[Piotr P. Karwasz]

Hi Volkan,

On Mon, 11 Dec 2023 at 10:26, Volkan Yazıcı  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

Re: Versioning scheme

[Robert Middleton]

remove method/class OR change method arguments OR class size
changes(C++) = major version bump
add new method/class = minor version bump
change/fix behavior without adding new method = patch

That should be the criteria for when to bump, at least according to
semver as far as I understand.

-Robert Middleton

On Mon, Dec 11, 2023 at 11:15 AM Christian Grobmeier
 wrote:
>
> Hi Volkan,
>
> I am not sure what you are proposing.
>
> On Mon, Dec 11, 2023, at 10:26, Volkan Yazıcı wrote:
> > I propose embracing a common versioning scheme across all Logging Services
> > projects; log4j, log4cxx, etc.
>
> As you already mentioned, except for some parts of Log4j 1, we are following 
> server already, and it looks like everybody knows about it.
>
> > match the `[0-9]+(-(alpha|beta)[1-9]+)?` That is, only the following will
> > be valid: `1.2.3`, `1.2.3-alpha4`, `1.2.3-beta4`, etc.
>
> We have only 3.0.0 with the alpha label. You are not against it, I guess?
>
> >- *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*
> >
> > 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.
>
> I assume with "issue" and "fix" you mean "bug fix".
>
> I don't understand what is the difference to what semver says.
> When you add functionality, it's a minor. If you just add fixes, it's a patch.
> Did I miss something that we are doing differently?

Re: Versioning scheme

[Christian Grobmeier]

Hi Volkan,

I am not sure what you are proposing.

On Mon, Dec 11, 2023, at 10:26, Volkan Yazıcı wrote:
> I propose embracing a common versioning scheme across all Logging Services
> projects; log4j, log4cxx, etc. 

As you already mentioned, except for some parts of Log4j 1, we are following 
server already, and it looks like everybody knows about it.

> match the `[0-9]+(-(alpha|beta)[1-9]+)?` That is, only the following will
> be valid: `1.2.3`, `1.2.3-alpha4`, `1.2.3-beta4`, etc.

We have only 3.0.0 with the alpha label. You are not against it, I guess?

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

I assume with "issue" and "fix" you mean "bug fix".

I don't understand what is the difference to what semver says. 
When you add functionality, it's a minor. If you just add fixes, it's a patch.
Did I miss something that we are doing differently?

Versioning scheme

[Volkan Yazıcı]

I propose embracing a common versioning scheme across all Logging Services
projects; log4j, log4cxx, etc. This will make it clear for maintainers
which version number to choose for the upcoming release, and ease for users
to what to expect from each release. If we have a consensus, we can
document this in logging.apache.org.

I propose adhering to the semantic versioning  (aka,
"semver"), plus some extra constraints for simplification. For one, judging
from the content in archive.apache.org/dist/logging, all our recent
releases follow the `major.minor.patch` scheme, which is in line with
semver. Though I suggest augmenting semver from two aspects.

*Limit `patch` pattern*

The definition of `patch` is pretty liberal. For instance, this is a valid
semver: `1.0.0-beta+exp.sha.5114f85`. Maybe we should limit the `patch` to
match the `[0-9]+(-(alpha|beta)[1-9]+)?` That is, only the following will
be valid: `1.2.3`, `1.2.3-alpha4`, `1.2.3-beta4`, etc.

*Refine semantics*

Semver has the following official definition:

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

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.

[VOTE][LAZY] Release Apache Logging Parent 10.5.0 (RC2)

[Volkan Yazıcı]

This is a lazy-vote to release the Apache Logging Parent version `10.5.0` (RC2).

Website: https://logging.staged.apache.org/logging-parent
GitHub: https://github.com/apache/logging-parent
Commit: 9bb44007955fd892d31c8c65f02cfbdd03d461b3
Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1241
Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0

Please download, test, and cast your votes on this mailing list.

[ ] +1, release the artifacts
[ ] -1, don't release, because...

This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted.

=== Review kit

The minimum set of steps needed to review the uploaded distribution
files in the Subversion repository can be summarized as follows:

# Check out the distribution
svn co https://dist.apache.org/repos/... && cd $_

# Verify checksums
shasum --check *.sha512

# Verify signatures
wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
for sigFile in *.asc; do gpg --verify $sigFile; done

# Verify reproduciblity
umask 0022
unzip *-src.zip -d src
cd src
export NEXUS_REPO=https://repository.apache.org/content/...
sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO

=== Release notes

This minor release contains dependency updates and a change in the way
BND is employed.

BND Maven Plugins are upgraded to version `7.0.0`, which requires Java 17.
Log4j was the blocker for this upgrade and the issue is resolved in
apache/logging-log4j2#2021.

 Changed

* Switch from `bnd:jar` to `bnd:bnd-process` to improve integration
with the ecosystem; IDEs, Maven plugins, etc. (#69)
* Update `biz.aQute.bnd:bnd-baseline-maven-plugin` to version `7.0.0` (#78)
* Update `biz.aQute.bnd:bnd-maven-plugin` to version `7.0.0`
* Update `com.diffplug.spotless:spotless-maven-plugin` to version `2.41.1` (#70)
* Update `com.github.spotbugs:spotbugs-annotations` to version `4.8.2` (#68)
* Update `com.github.spotbugs:spotbugs-maven-plugin` to version `4.8.2.0` (#71)
* Update `org.apache:apache` to version `31` (#73)
* Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to
version `0.6.0` (#72)