yeah, something that creates an automated Changelog.MD file is better than
putting it in a github release.  If I understood the talks I went to
earlier, Apache does not like it when you create a "release" before you
actually vote on release candidates, etc.

I am +1 with an automated release, once we move to "full" github.

On Wed, May 17, 2017 at 1:22 PM, Dan Kirkwood <[email protected]> wrote:

> yeah -- what Hank said...
>
> On Wed, May 17, 2017 at 11:17 AM, Hank Beatty <[email protected]> wrote:
> > -1 for a manual changelog - doing a compare between branches/commits in
> > github is relatively simple.
> >
> > +1 for a scripted changelog -
> > https://github.com/skywinder/github-changelog-generator - There is even
> a
> > list of alternatives:
> > https://github.com/skywinder/Github-Changelog-Generator/
> wiki/Alternatives
> >
> > On 05/17/2017 12:52 PM, Phil Sorber wrote:
> >>
> >> Here is a link to an example script generated CHANGES file from Jira:
> >>
> >> https://raw.githubusercontent.com/apache/trafficserver/6.0.x/CHANGES
> >>
> >> On Wed, May 17, 2017 at 10:48 AM Phil Sorber <[email protected]> wrote:
> >>
> >>> The script can be updated to do Jira. ATS used a Jira version before
> they
> >>> went to github. You can also separate out easily. In fact, we did it
> more
> >>> easily with Jira than with github, since those categories are mutually
> >>> exclusive in Jira and labels in github are not. You could also have a
> >>> developer run the script regularly, or have CI do it.
> >>>
> >>> To Eric's comment, if you can make that indication in Jira/GitHub then
> >>> you
> >>> can transition that to the script. For example, a "Changelog" label in
> >>> github that would mean to have it included.
> >>>
> >>> On Wed, May 17, 2017 at 10:37 AM Eric Friedrich (efriedri) <
> >>> [email protected]> wrote:
> >>>
> >>>> 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