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>

Reply via email to