<jidanni(a)jidanni.org> wrote in message news:firstname.lastname@example.org...
C> On Sun, Jan 16, 2011 at 7:16 PM, Happy-melon
> Isn't that what release notes are for?
Say, how do you pros see what changed?
Here is my extra stupid way. I do it every few weeks.
cp RELEASE-NOTES /tmp
diff --ignore-space-change -U0 /tmp RELEASE-NOTES
Often old lines are shown again, because somebody tidied their
formatting. A svn diff wouldn't be any better.
The worst thing is each 1.17 to 1.18, 1.18 to 1.19 change, when the
whole file changes.
So how do you folks track RELEASE-NOTES level changes (not source code
level changes, too many), coinciding with your SVN updates?
One generally gets information out of a release notes file by reading it.
The purpose of release notes is to be a list of changes between versions; if
I want to upgrade from 1.15 to 1.17, I read the 1.16 and 1.17 release notes,
and I know all the changes I should be expecting. Why would I want the 1.16
release notes to contain changes which do not affect 1.16?
If you are determined to deploy bleeding-edge code on production sites, you
will need to be a little more adventurous in getting hold of the latest
changes. You can go to  and select the latest revision, and the last
revision you checked out, and read the diff in a slightly prettier format.
Pretty much by definition, there isn't a nicer way of reading them.