Documenting new upstream version in ‘debian/changelog’ (was: Uploaded)
Adeodato Simó <email@example.com> writes:
> * Please only close bugs with a “New upstream version” message if
> they’re actually a wishlist bug asking for the new version to be
> packaged. In case they are actual bugs, please do something like:
> * New upstream release:
> + does not prepend “fast” to the “insane” preset. (Closes: #501925)
> + copes with lame sending --genre-list output to stderr.
> (Closes: #490082)
> + fixes genre parsin or whatever. (Closes: #517561)
> I hope you’ll agree that’s more useful for the person reading the
> changelog, and it only takes a bit more effort. No need to
> retroactively edit the changelog, though.
I wholeheartedly agree with this, and would go further: even if there
are no Debian BTS reports to close, you should *still* give the
highlights of a new upstream version in the ‘debian/changelog’.
I'm utterly uninformed by a bare “New upstream release.”; of course
it's a new upstream release, I can already see that from the version
number. This is a changelog, tell me *what changed* in this new upstream
That's my morning rant out of the way, I hope you all enjoyed it as much
as I did.
\ “An idea isn't responsible for the people who believe in it.” |
`\ —Donald Robert Perry Marquis |