You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2017/01/27 18:20:08 UTC
Use of the manual change log
I was looking over the changelog for 2.8 and noticed some things in the
"Fixed Bugs" section that sound like they'd be more appropriate in the "New
features" section such as:
* Added Builder classes (e.g., GelfLayout)
* Make GelfLayout independent of Jackson (that is totally a new feature!)
* Added CleanableThreadContextMap (not only is it a new feature, it's a new
log4j-api class!)
* Any new options added to plugins (e.g., disableAnsi in PatternLayout)
* Configurable JVM shutdown hook timeout
* Garbage-free changes (unless you consider garbage objects to be a bug
now?)
Also, this isn't such a big deal, but when we do more than two dependency
version upgrades within a single release, it might be clearer to combine
them into a single ticket (e.g., Jackson makes a bit more releases than we
do, so we usually end up with multiple Jackson upgrade tickets in the
changelog which isn't very helpful to a user).
--
Matt Sicker <bo...@gmail.com>
Re: Use of the manual change log
Posted by Remko Popma <re...@gmail.com>.
I agree.
The release mail is out, but we can modify the blog post. If we modify changes.xml and regenerate the page we can manually update that page on the site as well.
I can modify the blog post but can someone else do the remainder if they want?
Sent from my iPhone
> On Jan 28, 2017, at 3:20, Matt Sicker <bo...@gmail.com> wrote:
>
> I was looking over the changelog for 2.8 and noticed some things in the "Fixed Bugs" section that sound like they'd be more appropriate in the "New features" section such as:
>
> * Added Builder classes (e.g., GelfLayout)
> * Make GelfLayout independent of Jackson (that is totally a new feature!)
> * Added CleanableThreadContextMap (not only is it a new feature, it's a new log4j-api class!)
> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
> * Configurable JVM shutdown hook timeout
> * Garbage-free changes (unless you consider garbage objects to be a bug now?)
>
> Also, this isn't such a big deal, but when we do more than two dependency version upgrades within a single release, it might be clearer to combine them into a single ticket (e.g., Jackson makes a bit more releases than we do, so we usually end up with multiple Jackson upgrade tickets in the changelog which isn't very helpful to a user).
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Use of the manual change log
Posted by Matt Sicker <bo...@gmail.com>.
I've updated the output format to be in markdown so it formats more nicely
on GitHub and provides an easier to copy/paste version of the release notes
for an announce email. Take a look: <
https://github.com/apache/logging-log4j2/blob/master/RELEASE-NOTES.md>
On 27 January 2017 at 21:53, Matt Sicker <bo...@gmail.com> wrote:
> I don't mind having a manual changelog (I do it in a personal project
> myself). I'd just like to know how to properly use it category-wise as it's
> been somewhat inconsistent in where to put things both in category and in
> order. And like I mentioned, it'd be a lot of pointless work to update the
> old tickets in jira to match the existing changes.xml file as it is. When
> it comes to entries in changes.xml, mine are usually copy/paste from the
> jira ticket as it is, though sometimes it might be slightly longer.
>
> On 27 January 2017 at 21:39, Remko Popma <re...@gmail.com> wrote:
>
>> I like having them separate:
>>
>> When I engage on JIRA I can focus on solving the problem and
>> communicating with stakeholders on what the trade offs are. I don't need to
>> worry about presentation.
>>
>> In the changes.xml I can take a step back and think of how I want to
>> present the resulting actual changes. Doing this as a separate step helps
>> me see the bigger picture.
>>
>> And overhead is minimal anyway.
>>
>> Sent from my iPhone
>>
>> On Jan 28, 2017, at 10:36, Matt Sicker <bo...@gmail.com> wrote:
>>
>> The changelog from jira can look just as good as the manually managed one
>> as long as jira tickets have a descriptive title like our manual changelog
>> does. I'd link to the snapshot version of Log4j Boot's site, but Jenkins
>> isn't able to talk to Jira for some reason.
>>
>> On 27 January 2017 at 18:15, Remko Popma <re...@gmail.com> wrote:
>>
>>> When you say change, you mean update? (I thought there were only 4
>>> categories: add, fix, update and delete.)
>>>
>>> I don't mind using the update category for improvements in the future,
>>> just that the difference between new feature and improvement is
>>> sometimes not clear-cut.
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 28, 2017, at 3:58, Apache <ra...@dslextreme.com> wrote:
>>>
>>> I wouldn’t call making GelfLayout independent of Jackson a new feature
>>> since it wouldn’t affect the external behavior other than the dependencies.
>>> I would have marked it as a change. I would have done the same with all the
>>> “Avoid allocating temporary objects” issues. The way I look at it, is if it
>>> is something that is really new, such as an additional parameter or new
>>> external or internal component, then it belongs as a new feature. If it
>>> fixes a reported bug then it is a fix. Pretty much everything else is a
>>> change.
>>>
>>> Ralph
>>>
>>> On Jan 27, 2017, at 11:20 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I was looking over the changelog for 2.8 and noticed some things in the
>>> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
>>> features" section such as:
>>>
>>> * Added Builder classes (e.g., GelfLayout)
>>> * Make GelfLayout independent of Jackson (that is totally a new feature!)
>>> * Added CleanableThreadContextMap (not only is it a new feature, it's a
>>> new log4j-api class!)
>>> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
>>> * Configurable JVM shutdown hook timeout
>>> * Garbage-free changes (unless you consider garbage objects to be a bug
>>> now?)
>>>
>>> Also, this isn't such a big deal, but when we do more than two
>>> dependency version upgrades within a single release, it might be clearer to
>>> combine them into a single ticket (e.g., Jackson makes a bit more releases
>>> than we do, so we usually end up with multiple Jackson upgrade tickets in
>>> the changelog which isn't very helpful to a user).
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Use of the manual change log
Posted by Matt Sicker <bo...@gmail.com>.
I don't mind having a manual changelog (I do it in a personal project
myself). I'd just like to know how to properly use it category-wise as it's
been somewhat inconsistent in where to put things both in category and in
order. And like I mentioned, it'd be a lot of pointless work to update the
old tickets in jira to match the existing changes.xml file as it is. When
it comes to entries in changes.xml, mine are usually copy/paste from the
jira ticket as it is, though sometimes it might be slightly longer.
On 27 January 2017 at 21:39, Remko Popma <re...@gmail.com> wrote:
> I like having them separate:
>
> When I engage on JIRA I can focus on solving the problem and communicating
> with stakeholders on what the trade offs are. I don't need to worry about
> presentation.
>
> In the changes.xml I can take a step back and think of how I want to
> present the resulting actual changes. Doing this as a separate step helps
> me see the bigger picture.
>
> And overhead is minimal anyway.
>
> Sent from my iPhone
>
> On Jan 28, 2017, at 10:36, Matt Sicker <bo...@gmail.com> wrote:
>
> The changelog from jira can look just as good as the manually managed one
> as long as jira tickets have a descriptive title like our manual changelog
> does. I'd link to the snapshot version of Log4j Boot's site, but Jenkins
> isn't able to talk to Jira for some reason.
>
> On 27 January 2017 at 18:15, Remko Popma <re...@gmail.com> wrote:
>
>> When you say change, you mean update? (I thought there were only 4
>> categories: add, fix, update and delete.)
>>
>> I don't mind using the update category for improvements in the future,
>> just that the difference between new feature and improvement is
>> sometimes not clear-cut.
>>
>> Sent from my iPhone
>>
>> On Jan 28, 2017, at 3:58, Apache <ra...@dslextreme.com> wrote:
>>
>> I wouldn’t call making GelfLayout independent of Jackson a new feature
>> since it wouldn’t affect the external behavior other than the dependencies.
>> I would have marked it as a change. I would have done the same with all the
>> “Avoid allocating temporary objects” issues. The way I look at it, is if it
>> is something that is really new, such as an additional parameter or new
>> external or internal component, then it belongs as a new feature. If it
>> fixes a reported bug then it is a fix. Pretty much everything else is a
>> change.
>>
>> Ralph
>>
>> On Jan 27, 2017, at 11:20 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I was looking over the changelog for 2.8 and noticed some things in the
>> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
>> features" section such as:
>>
>> * Added Builder classes (e.g., GelfLayout)
>> * Make GelfLayout independent of Jackson (that is totally a new feature!)
>> * Added CleanableThreadContextMap (not only is it a new feature, it's a
>> new log4j-api class!)
>> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
>> * Configurable JVM shutdown hook timeout
>> * Garbage-free changes (unless you consider garbage objects to be a bug
>> now?)
>>
>> Also, this isn't such a big deal, but when we do more than two dependency
>> version upgrades within a single release, it might be clearer to combine
>> them into a single ticket (e.g., Jackson makes a bit more releases than we
>> do, so we usually end up with multiple Jackson upgrade tickets in the
>> changelog which isn't very helpful to a user).
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Use of the manual change log
Posted by Remko Popma <re...@gmail.com>.
I like having them separate:
When I engage on JIRA I can focus on solving the problem and communicating with stakeholders on what the trade offs are. I don't need to worry about presentation.
In the changes.xml I can take a step back and think of how I want to present the resulting actual changes. Doing this as a separate step helps me see the bigger picture.
And overhead is minimal anyway.
Sent from my iPhone
> On Jan 28, 2017, at 10:36, Matt Sicker <bo...@gmail.com> wrote:
>
> The changelog from jira can look just as good as the manually managed one as long as jira tickets have a descriptive title like our manual changelog does. I'd link to the snapshot version of Log4j Boot's site, but Jenkins isn't able to talk to Jira for some reason.
>
>> On 27 January 2017 at 18:15, Remko Popma <re...@gmail.com> wrote:
>> When you say change, you mean update? (I thought there were only 4 categories: add, fix, update and delete.)
>>
>> I don't mind using the update category for improvements in the future, just that the difference between new feature and improvement is sometimes not clear-cut.
>>
>> Sent from my iPhone
>>
>>> On Jan 28, 2017, at 3:58, Apache <ra...@dslextreme.com> wrote:
>>>
>>> I wouldn’t call making GelfLayout independent of Jackson a new feature since it wouldn’t affect the external behavior other than the dependencies. I would have marked it as a change. I would have done the same with all the “Avoid allocating temporary objects” issues. The way I look at it, is if it is something that is really new, such as an additional parameter or new external or internal component, then it belongs as a new feature. If it fixes a reported bug then it is a fix. Pretty much everything else is a change.
>>>
>>> Ralph
>>>
>>>> On Jan 27, 2017, at 11:20 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I was looking over the changelog for 2.8 and noticed some things in the "Fixed Bugs" section that sound like they'd be more appropriate in the "New features" section such as:
>>>>
>>>> * Added Builder classes (e.g., GelfLayout)
>>>> * Make GelfLayout independent of Jackson (that is totally a new feature!)
>>>> * Added CleanableThreadContextMap (not only is it a new feature, it's a new log4j-api class!)
>>>> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
>>>> * Configurable JVM shutdown hook timeout
>>>> * Garbage-free changes (unless you consider garbage objects to be a bug now?)
>>>>
>>>> Also, this isn't such a big deal, but when we do more than two dependency version upgrades within a single release, it might be clearer to combine them into a single ticket (e.g., Jackson makes a bit more releases than we do, so we usually end up with multiple Jackson upgrade tickets in the changelog which isn't very helpful to a user).
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Use of the manual change log
Posted by Matt Sicker <bo...@gmail.com>.
The changelog from jira can look just as good as the manually managed one
as long as jira tickets have a descriptive title like our manual changelog
does. I'd link to the snapshot version of Log4j Boot's site, but Jenkins
isn't able to talk to Jira for some reason.
On 27 January 2017 at 18:15, Remko Popma <re...@gmail.com> wrote:
> When you say change, you mean update? (I thought there were only 4
> categories: add, fix, update and delete.)
>
> I don't mind using the update category for improvements in the future,
> just that the difference between new feature and improvement is sometimes
> not clear-cut.
>
> Sent from my iPhone
>
> On Jan 28, 2017, at 3:58, Apache <ra...@dslextreme.com> wrote:
>
> I wouldn’t call making GelfLayout independent of Jackson a new feature
> since it wouldn’t affect the external behavior other than the dependencies.
> I would have marked it as a change. I would have done the same with all the
> “Avoid allocating temporary objects” issues. The way I look at it, is if it
> is something that is really new, such as an additional parameter or new
> external or internal component, then it belongs as a new feature. If it
> fixes a reported bug then it is a fix. Pretty much everything else is a
> change.
>
> Ralph
>
> On Jan 27, 2017, at 11:20 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> I was looking over the changelog for 2.8 and noticed some things in the
> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
> features" section such as:
>
> * Added Builder classes (e.g., GelfLayout)
> * Make GelfLayout independent of Jackson (that is totally a new feature!)
> * Added CleanableThreadContextMap (not only is it a new feature, it's a
> new log4j-api class!)
> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
> * Configurable JVM shutdown hook timeout
> * Garbage-free changes (unless you consider garbage objects to be a bug
> now?)
>
> Also, this isn't such a big deal, but when we do more than two dependency
> version upgrades within a single release, it might be clearer to combine
> them into a single ticket (e.g., Jackson makes a bit more releases than we
> do, so we usually end up with multiple Jackson upgrade tickets in the
> changelog which isn't very helpful to a user).
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Use of the manual change log
Posted by Mikael Ståldal <mi...@magine.com>.
I added a comment at the top of changes.xml to clarify this.
On Fri, Feb 10, 2017 at 4:13 AM, Matt Sicker <bo...@gmail.com> wrote:
> That changes because that's how the template is configured: <
> https://github.com/apache/logging-log4j2/blob/master/
> src/changes/announcement.vm#L94>. It could be changed to whatever. The
> template should be a bit simpler to figure out now that it's been macro'd a
> bit.
>
> On 2 February 2017 at 14:45, Mikael Ståldal <mi...@magine.com>
> wrote:
>
>> It is a bit confusing that "update" in changes.xml translates to
>> "Changes" in release notes. Why is it so?
>>
>> On Jan 28, 2017 1:16 AM, "Remko Popma" <re...@gmail.com> wrote:
>>
>>> When you say change, you mean update? (I thought there were only 4
>>> categories: add, fix, update and delete.)
>>>
>>> I don't mind using the update category for improvements in the future,
>>> just that the difference between new feature and improvement is
>>> sometimes not clear-cut.
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 28, 2017, at 3:58, Apache <ra...@dslextreme.com> wrote:
>>>
>>> I wouldn’t call making GelfLayout independent of Jackson a new feature
>>> since it wouldn’t affect the external behavior other than the dependencies.
>>> I would have marked it as a change. I would have done the same with all the
>>> “Avoid allocating temporary objects” issues. The way I look at it, is if it
>>> is something that is really new, such as an additional parameter or new
>>> external or internal component, then it belongs as a new feature. If it
>>> fixes a reported bug then it is a fix. Pretty much everything else is a
>>> change.
>>>
>>> Ralph
>>>
>>> On Jan 27, 2017, at 11:20 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I was looking over the changelog for 2.8 and noticed some things in the
>>> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
>>> features" section such as:
>>>
>>> * Added Builder classes (e.g., GelfLayout)
>>> * Make GelfLayout independent of Jackson (that is totally a new feature!)
>>> * Added CleanableThreadContextMap (not only is it a new feature, it's a
>>> new log4j-api class!)
>>> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
>>> * Configurable JVM shutdown hook timeout
>>> * Garbage-free changes (unless you consider garbage objects to be a bug
>>> now?)
>>>
>>> Also, this isn't such a big deal, but when we do more than two
>>> dependency version upgrades within a single release, it might be clearer to
>>> combine them into a single ticket (e.g., Jackson makes a bit more releases
>>> than we do, so we usually end up with multiple Jackson upgrade tickets in
>>> the changelog which isn't very helpful to a user).
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Use of the manual change log
Posted by Matt Sicker <bo...@gmail.com>.
That changes because that's how the template is configured: <
https://github.com/apache/logging-log4j2/blob/master/src/changes/announcement.vm#L94>.
It could be changed to whatever. The template should be a bit simpler to
figure out now that it's been macro'd a bit.
On 2 February 2017 at 14:45, Mikael Ståldal <mi...@magine.com>
wrote:
> It is a bit confusing that "update" in changes.xml translates to "Changes"
> in release notes. Why is it so?
>
> On Jan 28, 2017 1:16 AM, "Remko Popma" <re...@gmail.com> wrote:
>
>> When you say change, you mean update? (I thought there were only 4
>> categories: add, fix, update and delete.)
>>
>> I don't mind using the update category for improvements in the future,
>> just that the difference between new feature and improvement is
>> sometimes not clear-cut.
>>
>> Sent from my iPhone
>>
>> On Jan 28, 2017, at 3:58, Apache <ra...@dslextreme.com> wrote:
>>
>> I wouldn’t call making GelfLayout independent of Jackson a new feature
>> since it wouldn’t affect the external behavior other than the dependencies.
>> I would have marked it as a change. I would have done the same with all the
>> “Avoid allocating temporary objects” issues. The way I look at it, is if it
>> is something that is really new, such as an additional parameter or new
>> external or internal component, then it belongs as a new feature. If it
>> fixes a reported bug then it is a fix. Pretty much everything else is a
>> change.
>>
>> Ralph
>>
>> On Jan 27, 2017, at 11:20 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I was looking over the changelog for 2.8 and noticed some things in the
>> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
>> features" section such as:
>>
>> * Added Builder classes (e.g., GelfLayout)
>> * Make GelfLayout independent of Jackson (that is totally a new feature!)
>> * Added CleanableThreadContextMap (not only is it a new feature, it's a
>> new log4j-api class!)
>> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
>> * Configurable JVM shutdown hook timeout
>> * Garbage-free changes (unless you consider garbage objects to be a bug
>> now?)
>>
>> Also, this isn't such a big deal, but when we do more than two dependency
>> version upgrades within a single release, it might be clearer to combine
>> them into a single ticket (e.g., Jackson makes a bit more releases than we
>> do, so we usually end up with multiple Jackson upgrade tickets in the
>> changelog which isn't very helpful to a user).
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
--
Matt Sicker <bo...@gmail.com>
Re: Use of the manual change log
Posted by Mikael Ståldal <mi...@magine.com>.
It is a bit confusing that "update" in changes.xml translates to "Changes"
in release notes. Why is it so?
On Jan 28, 2017 1:16 AM, "Remko Popma" <re...@gmail.com> wrote:
> When you say change, you mean update? (I thought there were only 4
> categories: add, fix, update and delete.)
>
> I don't mind using the update category for improvements in the future,
> just that the difference between new feature and improvement is sometimes
> not clear-cut.
>
> Sent from my iPhone
>
> On Jan 28, 2017, at 3:58, Apache <ra...@dslextreme.com> wrote:
>
> I wouldn’t call making GelfLayout independent of Jackson a new feature
> since it wouldn’t affect the external behavior other than the dependencies.
> I would have marked it as a change. I would have done the same with all the
> “Avoid allocating temporary objects” issues. The way I look at it, is if it
> is something that is really new, such as an additional parameter or new
> external or internal component, then it belongs as a new feature. If it
> fixes a reported bug then it is a fix. Pretty much everything else is a
> change.
>
> Ralph
>
> On Jan 27, 2017, at 11:20 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> I was looking over the changelog for 2.8 and noticed some things in the
> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
> features" section such as:
>
> * Added Builder classes (e.g., GelfLayout)
> * Make GelfLayout independent of Jackson (that is totally a new feature!)
> * Added CleanableThreadContextMap (not only is it a new feature, it's a
> new log4j-api class!)
> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
> * Configurable JVM shutdown hook timeout
> * Garbage-free changes (unless you consider garbage objects to be a bug
> now?)
>
> Also, this isn't such a big deal, but when we do more than two dependency
> version upgrades within a single release, it might be clearer to combine
> them into a single ticket (e.g., Jackson makes a bit more releases than we
> do, so we usually end up with multiple Jackson upgrade tickets in the
> changelog which isn't very helpful to a user).
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
Re: Use of the manual change log
Posted by Remko Popma <re...@gmail.com>.
When you say change, you mean update? (I thought there were only 4 categories: add, fix, update and delete.)
I don't mind using the update category for improvements in the future, just that the difference between new feature and improvement is sometimes not clear-cut.
Sent from my iPhone
> On Jan 28, 2017, at 3:58, Apache <ra...@dslextreme.com> wrote:
>
> I wouldn’t call making GelfLayout independent of Jackson a new feature since it wouldn’t affect the external behavior other than the dependencies. I would have marked it as a change. I would have done the same with all the “Avoid allocating temporary objects” issues. The way I look at it, is if it is something that is really new, such as an additional parameter or new external or internal component, then it belongs as a new feature. If it fixes a reported bug then it is a fix. Pretty much everything else is a change.
>
> Ralph
>
>> On Jan 27, 2017, at 11:20 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I was looking over the changelog for 2.8 and noticed some things in the "Fixed Bugs" section that sound like they'd be more appropriate in the "New features" section such as:
>>
>> * Added Builder classes (e.g., GelfLayout)
>> * Make GelfLayout independent of Jackson (that is totally a new feature!)
>> * Added CleanableThreadContextMap (not only is it a new feature, it's a new log4j-api class!)
>> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
>> * Configurable JVM shutdown hook timeout
>> * Garbage-free changes (unless you consider garbage objects to be a bug now?)
>>
>> Also, this isn't such a big deal, but when we do more than two dependency version upgrades within a single release, it might be clearer to combine them into a single ticket (e.g., Jackson makes a bit more releases than we do, so we usually end up with multiple Jackson upgrade tickets in the changelog which isn't very helpful to a user).
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
Re: Use of the manual change log
Posted by Apache <ra...@dslextreme.com>.
I wouldn’t call making GelfLayout independent of Jackson a new feature since it wouldn’t affect the external behavior other than the dependencies. I would have marked it as a change. I would have done the same with all the “Avoid allocating temporary objects” issues. The way I look at it, is if it is something that is really new, such as an additional parameter or new external or internal component, then it belongs as a new feature. If it fixes a reported bug then it is a fix. Pretty much everything else is a change.
Ralph
> On Jan 27, 2017, at 11:20 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> I was looking over the changelog for 2.8 and noticed some things in the "Fixed Bugs" section that sound like they'd be more appropriate in the "New features" section such as:
>
> * Added Builder classes (e.g., GelfLayout)
> * Make GelfLayout independent of Jackson (that is totally a new feature!)
> * Added CleanableThreadContextMap (not only is it a new feature, it's a new log4j-api class!)
> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
> * Configurable JVM shutdown hook timeout
> * Garbage-free changes (unless you consider garbage objects to be a bug now?)
>
> Also, this isn't such a big deal, but when we do more than two dependency version upgrades within a single release, it might be clearer to combine them into a single ticket (e.g., Jackson makes a bit more releases than we do, so we usually end up with multiple Jackson upgrade tickets in the changelog which isn't very helpful to a user).
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Use of the manual change log
Posted by Remko Popma <re...@gmail.com>.
I actually like that the change log is generated from a manually maintained changes.xml. This results in a much higher quality change log than if it were automatically generated from Jira.
Remko
Sent from my iPhone
> On Jan 28, 2017, at 4:26, Matt Sicker <bo...@gmail.com> wrote:
>
> Oh, I see about the different versions. Users may not be on the latest version, so seeing that it works with the versions in between can be useful.
>
> Some general clarification on the categories in changes.xml would help a bit, too, since we all need to manually add them ourselves. Ideally, we'd be able to generate this from jira, but that would require going back and modified hundreds of tickets. I started using that style for Log4j Boot so I wouldn't need to maintain two changelogs.
>
>> On 27 January 2017 at 13:03, Gary Gregory <ga...@gmail.com> wrote:
>> Sure, that would be one way to do it as well.
>>
>> Gary
>>
>>> On Fri, Jan 27, 2017 at 10:59 AM, Apache <ra...@dslextreme.com> wrote:
>>> I would reuse the same Jira issue and modify the changes entry to indicate that both were tested.
>>>
>>> Ralph
>>>
>>>> On Jan 27, 2017, at 11:54 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>
>>>> I like the multiple entries because it shows that we've (presumably, which I did with a full build) tested each Jackson version. It shows that we track releases and that we took the care to test and keep up. That may matter to some and not so much to others...
>>>>
>>>> Gary
>>>>
>>>>> On Jan 27, 2017 10:21 AM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>>> I was looking over the changelog for 2.8 and noticed some things in the "Fixed Bugs" section that sound like they'd be more appropriate in the "New features" section such as:
>>>>>
>>>>> * Added Builder classes (e.g., GelfLayout)
>>>>> * Make GelfLayout independent of Jackson (that is totally a new feature!)
>>>>> * Added CleanableThreadContextMap (not only is it a new feature, it's a new log4j-api class!)
>>>>> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
>>>>> * Configurable JVM shutdown hook timeout
>>>>> * Garbage-free changes (unless you consider garbage objects to be a bug now?)
>>>>>
>>>>> Also, this isn't such a big deal, but when we do more than two dependency version upgrades within a single release, it might be clearer to combine them into a single ticket (e.g., Jackson makes a bit more releases than we do, so we usually end up with multiple Jackson upgrade tickets in the changelog which isn't very helpful to a user).
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Use of the manual change log
Posted by Matt Sicker <bo...@gmail.com>.
Oh, I see about the different versions. Users may not be on the latest
version, so seeing that it works with the versions in between can be useful.
Some general clarification on the categories in changes.xml would help a
bit, too, since we all need to manually add them ourselves. Ideally, we'd
be able to generate this from jira, but that would require going back and
modified hundreds of tickets. I started using that style for Log4j Boot so
I wouldn't need to maintain two changelogs.
On 27 January 2017 at 13:03, Gary Gregory <ga...@gmail.com> wrote:
> Sure, that would be one way to do it as well.
>
> Gary
>
> On Fri, Jan 27, 2017 at 10:59 AM, Apache <ra...@dslextreme.com>
> wrote:
>
>> I would reuse the same Jira issue and modify the changes entry to
>> indicate that both were tested.
>>
>> Ralph
>>
>> On Jan 27, 2017, at 11:54 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>> I like the multiple entries because it shows that we've (presumably,
>> which I did with a full build) tested each Jackson version. It shows that
>> we track releases and that we took the care to test and keep up. That may
>> matter to some and not so much to others...
>>
>> Gary
>>
>> On Jan 27, 2017 10:21 AM, "Matt Sicker" <bo...@gmail.com> wrote:
>>
>>> I was looking over the changelog for 2.8 and noticed some things in the
>>> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
>>> features" section such as:
>>>
>>> * Added Builder classes (e.g., GelfLayout)
>>> * Make GelfLayout independent of Jackson (that is totally a new feature!)
>>> * Added CleanableThreadContextMap (not only is it a new feature, it's a
>>> new log4j-api class!)
>>> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
>>> * Configurable JVM shutdown hook timeout
>>> * Garbage-free changes (unless you consider garbage objects to be a bug
>>> now?)
>>>
>>> Also, this isn't such a big deal, but when we do more than two
>>> dependency version upgrades within a single release, it might be clearer to
>>> combine them into a single ticket (e.g., Jackson makes a bit more releases
>>> than we do, so we usually end up with multiple Jackson upgrade tickets in
>>> the changelog which isn't very helpful to a user).
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: Use of the manual change log
Posted by Gary Gregory <ga...@gmail.com>.
Sure, that would be one way to do it as well.
Gary
On Fri, Jan 27, 2017 at 10:59 AM, Apache <ra...@dslextreme.com> wrote:
> I would reuse the same Jira issue and modify the changes entry to indicate
> that both were tested.
>
> Ralph
>
> On Jan 27, 2017, at 11:54 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> I like the multiple entries because it shows that we've (presumably, which
> I did with a full build) tested each Jackson version. It shows that we
> track releases and that we took the care to test and keep up. That may
> matter to some and not so much to others...
>
> Gary
>
> On Jan 27, 2017 10:21 AM, "Matt Sicker" <bo...@gmail.com> wrote:
>
>> I was looking over the changelog for 2.8 and noticed some things in the
>> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
>> features" section such as:
>>
>> * Added Builder classes (e.g., GelfLayout)
>> * Make GelfLayout independent of Jackson (that is totally a new feature!)
>> * Added CleanableThreadContextMap (not only is it a new feature, it's a
>> new log4j-api class!)
>> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
>> * Configurable JVM shutdown hook timeout
>> * Garbage-free changes (unless you consider garbage objects to be a bug
>> now?)
>>
>> Also, this isn't such a big deal, but when we do more than two dependency
>> version upgrades within a single release, it might be clearer to combine
>> them into a single ticket (e.g., Jackson makes a bit more releases than we
>> do, so we usually end up with multiple Jackson upgrade tickets in the
>> changelog which isn't very helpful to a user).
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Use of the manual change log
Posted by Apache <ra...@dslextreme.com>.
I would reuse the same Jira issue and modify the changes entry to indicate that both were tested.
Ralph
> On Jan 27, 2017, at 11:54 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> I like the multiple entries because it shows that we've (presumably, which I did with a full build) tested each Jackson version. It shows that we track releases and that we took the care to test and keep up. That may matter to some and not so much to others...
>
> Gary
>
> On Jan 27, 2017 10:21 AM, "Matt Sicker" <boards@gmail.com <ma...@gmail.com>> wrote:
> I was looking over the changelog for 2.8 and noticed some things in the "Fixed Bugs" section that sound like they'd be more appropriate in the "New features" section such as:
>
> * Added Builder classes (e.g., GelfLayout)
> * Make GelfLayout independent of Jackson (that is totally a new feature!)
> * Added CleanableThreadContextMap (not only is it a new feature, it's a new log4j-api class!)
> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
> * Configurable JVM shutdown hook timeout
> * Garbage-free changes (unless you consider garbage objects to be a bug now?)
>
> Also, this isn't such a big deal, but when we do more than two dependency version upgrades within a single release, it might be clearer to combine them into a single ticket (e.g., Jackson makes a bit more releases than we do, so we usually end up with multiple Jackson upgrade tickets in the changelog which isn't very helpful to a user).
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Use of the manual change log
Posted by Gary Gregory <ga...@gmail.com>.
I like the multiple entries because it shows that we've (presumably, which
I did with a full build) tested each Jackson version. It shows that we
track releases and that we took the care to test and keep up. That may
matter to some and not so much to others...
Gary
On Jan 27, 2017 10:21 AM, "Matt Sicker" <bo...@gmail.com> wrote:
> I was looking over the changelog for 2.8 and noticed some things in the
> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
> features" section such as:
>
> * Added Builder classes (e.g., GelfLayout)
> * Make GelfLayout independent of Jackson (that is totally a new feature!)
> * Added CleanableThreadContextMap (not only is it a new feature, it's a
> new log4j-api class!)
> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
> * Configurable JVM shutdown hook timeout
> * Garbage-free changes (unless you consider garbage objects to be a bug
> now?)
>
> Also, this isn't such a big deal, but when we do more than two dependency
> version upgrades within a single release, it might be clearer to combine
> them into a single ticket (e.g., Jackson makes a bit more releases than we
> do, so we usually end up with multiple Jackson upgrade tickets in the
> changelog which isn't very helpful to a user).
>
> --
> Matt Sicker <bo...@gmail.com>
>