Re: changelog practice, unfinalised vs UNRELEASED vs ~version
- To: email@example.com
- Subject: Re: changelog practice, unfinalised vs UNRELEASED vs ~version
- From: Henrique de Moraes Holschuh <firstname.lastname@example.org>
- Date: Mon, 27 Mar 2017 16:47:02 -0300
- Message-id: <[🔎] 1490644022.673556.925213416.78E3E512@webmail.messagingengine.com>
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.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. 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  asks for
changelog-updating commits before release (or maybe at the tip of every
ready-for-integration branch, etc), but...
 refer to dpkg-mergechangelogs(1) for the git driver for
debian/changelog, for example.
 as in "less busywork" while hacking, and no weird (and possibly
maintenance-hell-creating) disparity from commit log contents to in-tree
Henrique de Moraes Holschuh <email@example.com>