What about a compromise where developer chooses whether or not a 
feature/important fix is worth mentioning in the release notes. This would be 
at feature granularity not individual commit. 

Then at release build time, a script gathers from JIRA/Github API all fixes 
that were committed in that release and checks that into repo. 

—Eric

> On May 17, 2017, at 12:18 PM, Phil Sorber <[email protected]> wrote:
> 
> Don't we have a script that can generate this? ATS had this for a long time
> and it became a huge hassle. It caused merge conflicts all the time, that
> while easy to address, were a huge nuisance. It also ended up out of date
> often.
> 
> On Wed, May 17, 2017 at 10:11 AM Gelinas, Derek <[email protected]>
> wrote:
> 
>> +1 for sure. It'll also give us a way to scan the notes and see what needs
>> documenting and what doesn't yet have it.
>> 
>>> On May 17, 2017, at 11:44 AM, Dave Neuman <[email protected]> wrote:
>>> 
>>> Hey All,
>>> One thing we discussed at the meetup was the addition of a CHANGELOG.md
>>> file to the project.   This file will contain changes that are made to
>> the
>>> project including bug fixes and new features. (e.g.
>>> https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md).
>> Adding
>>> this file means that we will now require each PR to contain an update to
>>> the CHANGELOG.md file, and our documentation will need to be updated
>>> accordingly.
>>> I thought it would be good to open a vote for adding this file, and if it
>>> passes, I will update the documentation and add a CHANGELOG.md file.
>>> 
>>> Thanks,
>>> Dave
>> 

Reply via email to