Re: changelog practice, unfinalised vs UNRELEASED vs ~version
On Mon, 13 Feb 2017 at 10:53:18 -0600, Gunnar Wolf wrote:
> Interesting discussion. This (and not particularly your message, but
> this whole thread even leads me to questioning: Does our "finalized"
> changelog lines make *any* sense nowadays?
In the actual upload to the archive (as opposed to the version
under preparation in a VCS) it has value: it's the maintainer
responsible for deciding this unfinished change is ready to be
released to actual users. They might not even have contributed
any code: I'm pretty sure I've done team uploads where my only
input was to decide that my co-maintainers' actions added up to
a useful package update to send to the archive, and take
responsibility for that.
(Of course, the signoff line in the changelog is redundant with
the GPG signature, which is what actually matters but isn't at all
user-visible...)
> > * Write the changelog later: each commit just has a commit message
> > in a normal git way, and its debian/changelog is out of date.
> > At release time, write a cumulative debian/changelog entry for
> > everything that happened since the last release, finalize it and
> > commit it. The `gbp dch` command assumes this model (and is very
> > useful when following it).
>
> In the specific case of this team, we could most probably compose
> debian/changelog by reading git log since the last tag. But... I am
> not convinced I want to be constrained by this!
I'm not saying that should be *required*, only that it should be
*allowed*. In the work project where I'm closest to consistently using
this model, I often summarize the changelog a bit when making a release
rather than using `gbp dch` as-is, merging multiple commits' changelog
entries into a brief description of the feature that they add up to -
but the time of the release is a good time to do that, because then,
I have an overview of everything that happened since the last release.
S
Reply to: