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

[Jedrzej Nowacki]

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. 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.

Cheers,
  Jędrek