History

Making a Release¶

Contents

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 :

http://www.cruisecontrolnet.org/projects/ccnet/wiki

Options - scan rules :

+*.png +*.gif +*.jpg +*.css +*.js -ad.doubleclick.net/* -mime:application/foobar
-*ccnet/activity*
-*ccnet/roadmap*
-*ccnet/issues*
-*ccnet/time_entries*
-*ccnet/gantt*
-*ccnet/news*
-*ccnet/boards*
-*ccnet/files*
-*ccnet/repository*
-*ccnet/settings*
-*/edit
-http://www.cruisecontrolnet.org/watchers/*
-*/protect
-*/rename
-*/history

Options - links
also check : Get HTML files first

Options - Build
Site-structure - without 'www.domain.xxx'

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 SourceForge.net 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.

SourceForge¶

Login to the SourceForge.net 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

Chili¶

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

Login	Password

Wiki