Re: changelog practice, unfinalised vs UNRELEASED vs ~version

[Henrique de Moraes Holschuh <hmh@debian.org>]

On Tue, Feb 14, 2017, at 19:42, Ian Jackson wrote:
> Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED
> vs ~version"):
> > On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> > > I don't see how this complaint is any different from the need to merge,
> > > for example, changes to API documentation and test cases that accompany
> > > a functional change.
> > 
> > It's the difference between "sometimes conflicts" and "always conflicts".
> 
> This is a very real problem for debian/changelog, but mergechangelogs
> helps a lot.  In any case as I say I'm not trying to mandate the

Usable VCSes have pluggable merge drivers, and there are such drivers
for both GNU-style ChangeLog, and debian/changelog[1].  IME, they "just
work".  So, yeah, one *can* have the chagelog-update-along-with-change
workflow sanely most of the time nowadays.  

I would never use such an workflow unless forced, as I believe the
"proper commit log Tao" is better in the long run, and when your commit
logs are proper (and quite verbose), the natural workflow [2] asks for
changelog-updating commits before release (or maybe at the tip of every
ready-for-integration branch, etc), but...

[1] refer to dpkg-mergechangelogs(1) for the git driver for
debian/changelog, for example.

[2] as in "less busywork" while hacking, and no weird (and possibly
maintenance-hell-creating) disparity from commit log contents to in-tree
changelog contents.

-- 
  Henrique de Moraes Holschuh <hmh@debian.org>