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 <h...@debian.org>