that
> > worked the release notes would look terrible.
> >
> > Ralph.
> >
> > > On Dec 8, 2021, at 5:23 AM, Gary Gregory
> wrote:
> > >
> > > If you refer to
> > >
> https://logging.staged.apache.org/log4j/2.x/changes-report.html#a2.15.0
> > I&#x
orked the release notes would look terrible.
>
> Ralph.
>
> > On Dec 8, 2021, at 5:23 AM, Gary Gregory wrote:
> >
> > If you refer to
> > https://logging.staged.apache.org/log4j/2.x/changes-report.html#a2.15.0
> I'm
> > not sure what we can do unless
gt; not sure what we can do unless there is special sauce to use in
> changes.xml. Are we supposed to use HTML in a changes.xml entry? That would
> be simple enough.
>
> Gary
>
>> On Tue, Dec 7, 2021 at 5:05 PM Ralph Goers
>> wrote:
>>
>> Gary,
>>
>&
If you refer to
https://logging.staged.apache.org/log4j/2.x/changes-report.html#a2.15.0 I'm
not sure what we can do unless there is special sauce to use in
changes.xml. Are we supposed to use HTML in a changes.xml entry? That would
be simple enough.
Gary
On Tue, Dec 7, 2021 at 5:05 PM
Gary,
Please review the manual changes for 2.15.0 on the staging web site. The last
item is yours from
upgrading a bunch of dependency versions.
I spent a bunch of time yesterday trying to figure out how to make that pretty
and finally gave up.
It requires knowing now the changes plugin pass
I have copied the 2.14.1 of changes.xml from release-2.x to master and I
have removed the duplicates in the 3.0.0. Note that the 3.0.0 block in
master still needs to be grouped into fixes, updates, etc. sections. I will
do that grouping if you are okay with the previous change.
On Fri, Mar 5
; Are you gonna tidy it up or shall I give it a try?
>
>
> On Fri, Mar 5, 2021 at 7:23 AM Ralph Goers
> wrote:
>
>> Looking at changes.xml it looks like actions that are being fixed in
>> 2.14.1 in the release-2.x branch and 3.0.0 in master. This will create
>>
🤦♂️ I am in that group of people.
Thanks for the warning and sorry for the mess.
Are you gonna tidy it up or shall I give it a try?
On Fri, Mar 5, 2021 at 7:23 AM Ralph Goers
wrote:
> Looking at changes.xml it looks like actions that are being fixed in
> 2.14.1 in the release-2.x bran
Looking at changes.xml it looks like actions that are being fixed in 2.14.1 in
the release-2.x branch and 3.0.0 in master. This will create confusion for
users when 3.0.0 is released as we will be listing a pile of fixes that were
actually fixed in prior releases.
Please add the actions to
>> Talph,
>>
>> Feel free to edit changes.xml as you best see fit.
>>
>> Gary
>>
>> On Tue, Aug 13, 2019, 22:37 Ralph Goers
>> wrote:
>>
>>> The “By” column is a link to the team list that includes all your
>>> i
Just don’t remove any due-to changes from committers from before they
became committers.
On Wed, Aug 14, 2019 at 00:42, Gary Gregory wrote:
> Talph,
>
> Feel free to edit changes.xml as you best see fit.
>
> Gary
>
> On Tue, Aug 13, 2019, 22:37 Ralph Goers
> wrote:
&g
Talph,
Feel free to edit changes.xml as you best see fit.
Gary
On Tue, Aug 13, 2019, 22:37 Ralph Goers wrote:
> The “By” column is a link to the team list that includes all your
> information. If you don’t use your userid then the link won’t index into
> the list properly.
&g
>
>> Ralph
>>
>>> On Aug 13, 2019, at 8:13 PM, Ralph Goers
>> wrote:
>>>
>>> Gary,
>>>
>>> I am wondering why you have recently gotten in the habit of adding
>> yourself to the due-to field of changes.xml. Historically we hav
9, 20:13 Ralph Goers wrote:
>>
>> Gary,
>>
>> I am wondering why you have recently gotten in the habit of adding
>> yourself to the due-to field of changes.xml. Historically we have always
>> used that to give credit to non-committers who provide patches or
>>
due-to field of changes.xml. Historically we have always
> used that to give credit to non-committers who provide patches or
> significantly contribute to them. As committers we get credit in the
> source control and in the dev field of the action entry. It seems over the
> top to be
m wondering why you have recently gotten in the habit of adding
> yourself to the due-to field of changes.xml. Historically we have always
> used that to give credit to non-committers who provide patches or
> significantly contribute to them. As committers we get credit in the
> source c
giving yourself credit twice.
Ralph
> On Aug 13, 2019, at 8:13 PM, Ralph Goers wrote:
>
> Gary,
>
> I am wondering why you have recently gotten in the habit of adding yourself
> to the due-to field of changes.xml. Historically we have always used that to
> give credit to
Gary,
I am wondering why you have recently gotten in the habit of adding yourself to
the due-to field of changes.xml. Historically we have always used that to give
credit to non-committers who provide patches or significantly contribute to
them. As committers we get credit in the source
ething
> introduced in 3.0. Changes.xml should reflect the version the fix or feature
> was first added.
>
> Please remove the duplicates from 3.0.
>
> Ralph
>
> > On Jun 3, 2019, at 4:14 AM, Gary Gregory wrote:
> >
> > Are you sure? The reason I did it li
Am I sure about what? Who cares when the branches diverged? If a fix or feature
was introduced prior to 3.0 then it shouldn’t be listed as something introduced
in 3.0. Changes.xml should reflect the version the fix or feature was first
added.
Please remove the duplicates from 3.0.
Ralph
Are you sure? The reason I did it like this is to track changes from when
the branches diverged.
Gary
On Sun, Jun 2, 2019 at 5:45 PM Ralph Goers
wrote:
> Gary,
>
> In looking at the changes.xml in 3.0 it looks like you are adding
> notations to both the 2.x and 3.x releases. That
Gary,
In looking at the changes.xml in 3.0 it looks like you are adding notations to
both the 2.x and 3.x releases. That doesn’t make any sense. A change should be
noted ONLY in the release in which it was first published. Can you please go
through all the actions you added to the 3.0 release
The JIRA tickets themselves are still marked as Fixed Version 2.11, Gary,
would you mind updating them?
On Thu, Feb 1, 2018 at 9:09 PM, wrote:
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/master 041fe8ffe -> a9e8f525a
>
>
> Update changes.xml: moved JIRA
Doesn’t matter. When the release is performed the release plugin modifies all
the poms. The release manager only needs to know what the version should be.
Having the changes.xml reflect that is a good way to do it.
Ralph
> On Jan 18, 2018, at 9:23 AM, Gary Gregory wrote:
>
&g
Hi All:
Just FYI: The file changes.xml states 2.11.0 but POMs state 2.10.1
Gary
25 matches
Mail list logo
