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 <boa...@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 <remko.po...@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 <boa...@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 <remko.po...@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 <ralph.go...@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 <boa...@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 <boa...@gmail.com> >>> >>> >>> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> >> > > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
