Making a Release


Below are the steps needed for making a release of CCNet.
Providing a checklist ensures that nothing is forgotten :-)

Choose the release number.

Version format is in the form : X.Y.<buildnumber>.<fixedNumber>
This is different than before, and comes from the switch to GIT.

In most cases, x will remain the same and y will increase by 2 from the previous release.
Even numbers for Y are stable releases, odd numbers are nightly / CI builds.

Add a new dev version

This will normally be Y+2. Example : if we have a dev build of 1.7, the next dev build will be 1.9.
Settings - Versions - New Version

  • Version : X.Y+2
  • Description : CruiseControl.NET Dev X.Y+2
  • Sharing : With subprojects
  • WikiPage : version X.Y+2

Add a new release version

This will be Y+1. Example : if we have a dev build of 1.7, the next release build will be 1.8.
Settings - Versions - New Version

  • Version : X.Y+1
  • Description : CruiseControl.NET Dev X.Y+1
  • Sharing : With subprojects
  • WikiPage : version X.Y+1

Update links

Update the VersionInfo page so it has links to the new version(s)

Issue Management

Move any remaining issues (if any) to the next dev build, or remove the target version of them.

  • click on Roadmap
  • expand it
  • click on the version of the dev build
  • click on the XXX open link beneath the progress bar
  • move each item to the next dev build, or clear the target version

Release notes

The dev build will normally not have much manually written release notes, but it is a good practice to note big items in dev release notes.
Like breaking changes, big refactorings, config changes, ...
This way people trying out the dev builds have a guide of what's being altered, and making release notes for the Release build is a lot easier.
Copy this information, and massage it in a more user friendly form for the release notes of the Release build

Also copy the list of changes (bugs fixed, features) and the like as a list into the release build.
  • click on Roadmap
  • expand it
  • click on the version of the dev build
  • click on the XXX closed link beneath the progress bar
  • Copy the list into excel(do not use the export to csv as it has all columns and multi line)
  • just keep the columns tracker and subject(just keep values)
  • sort on tracker and subject
  • paste it below the written release notes, with a heading per type, each type has a h3 heading

Help pages

This part describes on updating the generated help on the wiki, and generating the off-line help documentation.

Update the wiki pages

  • Compile the source
  • create the wiki pages by running the createDocs.bat
  • now you have the wiki files in the docgen folder

Note : you can create and upload the docs by providing your wiki username and password as arguments like so :

1     createDocs.bat John Wayne

Create offline docs

When you uploaded the wiki pages, it is up to date concerning the documentation of tasks, publishers, ...
What remains is to create offline docs, as long as ChiliProject does not have a descent export function yet,
we can use HTTrack Website Copier. Below are the needed settings :

Web Adresses to download :

Options - scan rules :

+*.png +*.gif +*.jpg +*.css +*.js* -mime:application/foobar

Options - links
also check : Get HTML files first

Options - Build
Site-structure - without ''

Download the site, this will take about 2 - 3 minutes.
Copy the downloaded contents to the doc folder.
Commit this to the trunk.

Wait for CCNet live to pick up the changes.

Git adjustments

Create a new branch, with the version of the release number (the even one).

   todo : git statements

CCNet live adjustments

Adjust the projects of CCNet Live :
  • The dev build must get the new dev build number.
  • the release project must point to release branch and get the new release number

Force a build on the release project.

Upload packages

Get the latest build of the release project and upload it to SourceForge

  • Login to the website.
    1. Click on Account on middle-top of the page.
    2. Click on Projects
    3. Select CruiseControl.Net (you should arrive at the SourceForge CCNet Project site)
    4. Select Project Admin --> File Manager
    5. You'll see a folder structure with 3 sub folders :
        1. CruiseControl.NET Examples
        2. CruiseControl.NET Releases
        3. OldFiles
  • Create a new folder named according to the release (see other folders), by clicking on the cog wheel next to CruiseControl.NET Releases
  • Upload the files 1 by 1 by clicking on the cog wheel next to the newly created folder and select upload.
  • Make the setup exe te primary download for windows : click on the cog wheel next to the setup exe, and select properties.
  • On the window on the right side, check Windows, and press Save.
  • Go back to the main page of CCNet on Sourfeforge (SourceForge CCNet Project site)
  • edit the project settings , the second edit link you see.
  • Change the line Latest release to the correct number and mention the build number.

Inform the world.

Add news of the release on SourceForge and the Chili news blog.
Inform the mailing lists.


  • Login to the website.
  • Select the project to administer from the My Projects listing on the My Page.
  • Select Develop - News from the pulldown. If you don't have an Admin pulldown, you don't have the necessary privileges to continue the process.
  • Click on the Submit link near the top of the list.
  • Fill in the fields and submit the news item.
    Summary : CruiseControl.NET x.y released
    Details : paste the release Notes


Click on News, expand it, and fill in the fields.

Mailing lists

Sent information in the way you normally do.

Upgrade CCNet live

Install the latest version on CCNet live, just to show that we trust the version.

Some points for saving time :

  • Create the release notes a few days before the actual release, giving other devs also the chance to complete it, read it over, ...
  • Prepare the mail to be sent to the dev and user list in advance, and save it as a draft. So you do not have to do a quick write on the release day itself
  • When the release is a RC, state in the mail that an RC means it has to be tested with as much users as possible, include the points below :
    • use your existing config on a spare / virtual PC
    • test it with a couple of CCNet projects, one of every kind you have (CI, deploy, ...)
    • remove the labelling part of the scm so you do not interfere with the life/ production system
    • use the null task to simulate different build results (succeed, failed), eg.: for new publishers
    • use the null source control to simulate errors on source control operations, eg.: for new publishers