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>
