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>
