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/
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
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
serve
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
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*
> - *PA
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 un
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? F
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
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:*
> >
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
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 pat
The rule for this seems extremely simple to me. The changelog uses
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 t
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"*, pleas
14 matches
Mail list logo
