In my previous post I talked about how I managed to automatically download the release notes from our issue tracker web site. These notes still needed adding to our NEWs file, which describes the changes between releases.
There are really two scenarios to deal with here: the release notes for the current release either are already in the NEWS file, or they are not. They are already there when you rebuild the distribution for a release, for example when you’ve found something wrong with it and fixed that. For a human, this is pretty simple to detect, but how does an Ant script know?
Enter the Ant filter chain. This construct resembles a Unix pipe in that you can use it to feed output of one as input to the other. Here’s how I retrieve the version that is currently in the NEWS file:
<loadfile property="current.version"
srcFile="${news.file}>
<filterchain>
<headfilter lines="1"/>
<striplinebreaks>
<tokenfilter>
<replaceregex pattern="[a-zA-Z\s]*([1-9]+\.[0-9]+).*"
replace="\1"/>
<replacestring from="." to="\."/>
</tokenfilter>
</striplinebreaks>
</filterchain>
</loadfile>
The loadfile task loads the srcFile into the current.version property. But not just as is, no there is a filterchain applied first. The first item in the chain is headfilter, which works just like the Unix head command: in this case it gives the first line of the NEWS file. I don’t want a line, but a string, so next I remove the line ending with the striplinebreaks filter.
Then it’s time for some good old regular expression to extract the version number from the string. The first line of the NEWS file looks like this: Changes in 1.4.0. So I match the text with [a-zA-Z\s]* and then the actual version number with ([1-9]+\.[0-9]+).*.
Note that I use a group to capture only the major and minor version (1.4 in the previous example). The reason for that is that whenever we deliver patch releases, we don’t add a whole new section to the NEWS file, but just expand the current section with the few cases that were fixed by the patch. Since we sort the cases in descending order of reporting, the patch cases will always be at the top.
Following the regular expression there is a replacestring filter that inserts backslashes before points. The reason for that becomes clear when we look at how the Ant script actually uses the current.version property:
<condition property="same.release">
<matches string="${full.version}"
pattern="${current.version}"/>
</condition>
<antcall target="--remove-current-release-from-news"/>
<antcall target="--add-current-release-to-news"/>
The --remove-current-release-from-news target is only executed when the same.release property is true:
<target name="--remove-current-release-from-news"
if="same.release">
<property name="previous.version.file"
value="${news.dir}/previous.version.txt"/>
<echo message="${previous.version}"
file="${previous.version.file}"/>
<loadfile srcFile="${previous.version.file}"
property="escaped.previous.version">
<filterchain>
<tokenfilter>
<replacestring from="." to="\."/>
</tokenfilter><tokenfilter>
</tokenfilter>
</filterchain>
</loadfile>
<delete file="${previous.version.file}"/>
<replaceregexp file="${news.file}"
match=".*(Changes in ${escaped.previous.version}.*)"
replace="\1" flags="s"/>
</target>
The bulk of the work is done in the final replaceregexp task, where everything before the text Changes in <x>.<y>.<z> is deleted. The code before that is just a convoluted way to escape points in the previous version number. Unfortunately, I’m not aware of any Ant task that can execute a regular expression against a property, so I first put the property into a temporary file and then operate on that file.
Finally, all that is left, is to add the release notes for the current version to the NEWS file:
<target name="--add-current-release-to-news">
<property name="new.news.file"
value="${news.dir}/new.news.txt"/>
<concat destfile="${new.news.file}">
<path>
<pathelement location="${release.news.file}"/>
<pathelement location="${news.file}"/>
</path>
</concat>
<move file="${new.news.file}"
tofile="${news.file}"/>
<delete file="${release.news.file}"/>
</target>
The only tricky part here is that the concat task doesn’t allow one of its input files to also be the output file. So I have to introduce a temporary file. Then when all is done, the file containing the NEWS section for this release, release.news.file, is no longer needed.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
