[Development] dist/changes-x.y.z (was: Re: Branches)

[Marc Mutz]

On Friday December 7 2012, Jedrzej Nowacki wrote:
> On Thursday 6. December 2012 19.08.41 Olivier Goffart wrote:
> > On Thursday 06 December 2012 17:58:57 shane.kearns at accenture.com wrote:
> > > > Hi Lars,
> > > >
> > > > On Monday December 3 2012, Knoll Lars wrote:
> > > > > Dev:
> > > > >
> > > > > Dev is the branch where you can land anything that's supposed to go
> > > > > into 5.1. The following policies apply:
> > > > >
> > > > > * Changes have to be source and binary compatible
> > > > > * You can add new method and classes given that they are fully
> > > > > documented and tested * Please do not add half finished features.
> > > > > Create your own branch for that, and only push your changes once
> > > > > the
> > > >
> > > > feature is fully done.
> > > >
> > > > Should we add:
> > > >
> > > > * carries a change to dist/changes-5.1.0 if it's (Qt-)user-visible
> > > > (bug fixes,
> > > >
> > > >   new features, performance fixes)?
> > > >
> > > > Same for stable once 5.0.0 branches off?
> > >
> > > This would cause many more staging conflicts, as most changes would
> > > touch the same file. I'd suggest that bug fixes should not touch the
> > > changes file, only new features.
> >
> > I suggest we add a new header in our commit messages such as "Changelog:"
> > Someting that can be parsed to generate the changelog automatically.
>
> Hi,
>
>   Another alternative is to say that in dist/changes we should have only a
> major changes and bug fixes. It means that we need to filter every commit
> that has Qt bug number in it or it is a merge from a feature branch.

That would require allocating a bug number for every bug, something we don't 
currently do, but would indeed be nice to have.

But how would you filter 'major changes'? Or are you saying that they should 
be added to dist/changes in the commit that introduces them?

The latter would work for me, but you seem to be suggesting some other 
mechanism:

> The 
> alternative is nice, because it would work with the current work flow,
> without changing anything, we only need to be strict about feature merge
> commit message, it should be verbose, describing the feature. That is all,
> everything else can be generated from git log and jira.

The above sounds like sifting through a _lot_ of commits pre-5.1, which isn't 
really an attractive activity. Or are you saying that every new feature 
should have a JIRA issue, too?

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions