Bug 5846 - "Changes" file in distro should include human-readable changes list
Summary: "Changes" file in distro should include human-readable changes list
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Building & Packaging (show other bugs)
Version: unspecified
Hardware: Other other
: P5 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
Depends on:
Reported: 2008-03-06 02:36 UTC by Justin Mason
Modified: 2019-07-30 07:44 UTC (History)
1 user (show)

Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Mason 2008-03-06 02:36:26 UTC
I came across this again:


it's an old moan from Andy Lester about our changes file -- "Here's how to not
do a Changes file: That tells me nothing about whether I want to upgrade my
SpamAssassin install. :-("

it occurred to me that we still substantially have this problem.  I
suggest we fix it by changing our build process so that, instead of
generating "Changes" from svn log, we just cut and paste the history
of build/announcements/*.txt into a single top-level "Changes" file, e.g.

Summary of changes from 3.2.2:

- bug 5548: Certain mail input can take a long time to scan with 100% CPU
  utilisation, due to backtracking in a rule's regexp. fix

[... other changes omitted]

Summary of changes from 3.2.1:

3.2.1 is a major bug-fix release, including a potential local DoS.  The
major highlights are:

- bug 5480: fix for CVE-2007-2873: a local user symlink-attack DoS
  vulnerability. It only affects systems where spamd is run as root, is used
  with vpopmail or virtual users via the "-v"/"--vpopmail" OR
  "--virtual-config-dir" switch, AND with the "-x"/"--no-user-config AND
  WITHOUT the "-u"/"--username" switch AND with the "-l"/"--allow-tell" switch.
  This is not default on any distro package, and is not a common configuration.
  More details of the vulnerability can be read at

[... other changes omitted]

Summary of changes from 3.2.0:

Changes to the core code:

 * new behavior for trusted_networks/internal_networks: the 127.* network is now
always considered trusted and internal, regardless of configuration.

 * bug 3109: short-circuiting of 'definite ham' or 'definite spam' messages
based on individual short-circuit rules using the 'shortcircuit' setting, by
Dallas Engelken <dallase /at/ uribl.com>.

[... 3.2.0 changes omitted]

you get the idea.   As each release goes out, the manual gardening required
is basically just to cut and paste in the *current* release's changes block
into the file.

The svn log is, of course, still available -- in SVN.  so people who
want that can still get it.

sound good?
Comment 1 Daryl C. W. O'Shea 2008-03-06 14:05:58 UTC
sure, +1
Comment 2 Tom Schulz 2008-03-07 07:00:33 UTC
Could we have both types of change files?  Perhaps call the current type
of change file  Changes.svn  or some such.
Comment 3 Henrik Krohns 2019-07-30 07:44:13 UTC
Closing old stale bug. We already have UPGRADE file etc.