Best practices wrt. Changelog entries in spec file (upstream vs. specfile)

[Michael Schwendt]

On Sun, 30 Apr 2006 12:18:14 -0500, Jason L Tibbitts III wrote:

> >>>>> "MS" == Michael Schwendt <bugs.michael at gmx.net> writes:
> 
> MS> You can look _into_ rpms just fine and skim over any included
> MS> ChangeLog, NEWS, README files.
> 
> Please tell us how you would do so.  Assume the usual case, that the
> package is in a remote yum repo.

A fearful user downloads new packages and performs a test upgrade on a
test machine.

A fearful user knows that any shiny new version upgrade may lead to severe
regression, brown paperbag bugs, and other defects, regardless of how
upstream advertises the NEWS in their doc files.

If you mix upstream ChangeLog details and packaging %changelog details,
you create a blurred picture of who did what. Further, some upstream
developers are very verbose in their ChangeLogs, so as soon as you
started trying to sum up the changes in a new version, you would either
fail or end up copying the entire ChangeLog into your spec file.

In general, let users assume that a version upgrade is bigger'n'better
unless it failed during your packaging QA.

The majority of end-users are not interested in implementation details in
developer ChangeLogs unless they are confronted with run-time
misbehaviour. And even then, many of them don't read ChangeLogs to find
out which CVS commit may have been the culprit.

> Remember that we have no announcement mechanism for Extras packages,
> so we have no way to communicate possible incompatible updates to
> users.  Obviously the idea is to not introduce any incompatible
> changes within a single Fedora release, but eventually it's going to
> happen and surely a sentence in the %changelog can do nothing but
> help.

This belongs into the "spec %changelog should [...] cover important
changes in the packaging" as an incompatible version upgrade means that
you need to put a warning into your %changelog because _you created_ an
_incompatible package_.