[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Documenting new upstream version in ‘debian/changelog’ (was: Uploaded)

Adeodato Simó <dato@net.com.org.es> 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 |
_o__)                                                                  |
Ben Finney

Reply to: