Make Release Notes

Gerd provided a ruby script:

shortlog

#!/usr/bin/env ruby

require 'rubygems'
require 'hpricot'
require 'open-uri'

doc = Hpricot.XML($stdin)
doc.search("logentry") do |entry|
  revision=entry['revision']
  begin
    msg=entry.at('msg').inner_html.strip.split("\n")[0].strip.sub(/\.( .*)?$/, "")
    printf("<li><a href=\"http://www.dcache.org/WebSVN/listing.php?repname=dCache&amp;path=%%2F&amp;sc=1&amp;rev=%d\">[r%d]</a> %s</li>\n",revision,revision,msg)
  rescue
    STDERR.puts "Missing log statement for " + revision
    printf("<li><a href=\"http://www.dcache.org/WebSVN/listing.php?repname=dCache&amp;path=%%2F&amp;sc=1&amp;rev=%d\">[r%d]</a></li>\n",revision,revision)
  end
end

I placed the script in /SVN/dCache.

In /SVN/dCache/trunk run:

svn log --xml -r16654:HEAD | ../shortlog 

or similar.

Look at the changelog of the last release notes to find the last revision number.

Or have a look at  http://www.dcache.org/WebSVN/listing.php?repname=dCache&path=%2Fbranches%2F to find out at which revision number the code has been branched.

Use these number to run the script, e.g. for dCache 2.1

svn log --xml -r16654:HEAD | ../shortlog

e-mail from Gerd:

I usually start out producing the complete change log from the point of the creation of the previous branch to the head of the current branch.

Ie, in this case I checkout the 2.1 branch. Then I find the revision number at which the 2.0 branch was created and compute the changelog. I put this list into the HTML file, open it in a browser and then I start looking at each commit from the bottom up.

• For those commits that were merged from trunk into the 2.0 branch before 2.0.0 was released, I delete the changelog entry. These were part of 2.0.0 and there is no reason to include them in the 2.1.0 release notes.

• For those commits that were merged into the 2.0 branch after 2.0.0 was released, I mark them with 'class="stable"'. This causes them to be grey in the browser.

I rely on people adding 'Request: 2.0' tags in the commits they did to trunk. This way I recognize that they were intended for the stable release. I then click on the Patch: link in the commit to see the review board (RB) entry. The RB entry should have a link to a request tracker (RT) entry. The RT entry should mention whether the commit was actually merged into 2.0 or whether it was rejected. If people don't add the required tags (you will find that some people don't do this or don't follow the official format) then one has to resort to manual search through commit logs.

As you see, merges from trunk to the 2.1 branch are not a problem as you are producing the changelog from the 2.1 branch. You only have to extend the existing changelog just before the official release so that you get the latest merges included (ie you simply rerun the script using the revision of the last entry included + 1).

I usually manually exclude commits that are for the client tools (SRM and DCAP).