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, Volk
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 th
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
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 vers
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 upg
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 thr
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 <
>
> 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.
Act
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
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 pre
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 thin
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
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
>
>
>
>
>
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
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
The rule for this seems extremely simple to me. The changelog uses
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
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:*
> >
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
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
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
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
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,
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
24 matches
Mail list logo
