What's Coming?

This page is currently a work in progress. We are still in the process of looking at what to add in future releases.

Here are some of the things that we are planning for up-coming releases of CruiseControl.Net.

Release 1.5

Version 1.5.0 is feature complete - we are have stopped adding new functionality to this release.

Change mocking framework to Rhino.Mock (on-going)
Improve unit test coverage in the areas where it has diminished and where we are seeing bugs. The SVN source control block comes to mind. (on-going)
An automated build against mono? (completed)
Make NAnt build script platform independent (no hardcoded paths anymore, new msbuild task for xbuild compability, exclude some targets on linux (like the NIS installer, etc) (completed)

There will be a CTP release for 1.5.0 sometime in July, a RC release hopefully in October and the final release before the end of the year.

These are ideas of what we'd like to add in future. Little or no work has been done on these features yet.

Build agents (maybe use condor : http://www.cs.wisc.edu/condor/)
Configuration tools (CCNetConfig?)
Distributed build
Store build artifacts as separate files. And separate them from the build logs.
Store build history in a database of some kind: CouchDB, Rhino.Prevalence, the build-in Windows Jet Engine backed database facility.
Create a plugin system for CCTray. Voice, X10, build lights could be done as plugins. This would allow people to more easily support their own lights and other notification mechanisms.
Contact the CIFactory guys and find out if they are still interested in merging back any of their features to CCNet. Could be quite complex as they forked at 1.0. Could also be quite rewarding.
Refactor the dashboard to use an open source MVC framework (e.g. MonoRail, ASP.NET MVC, etc.)
Replace objection with an open source IoC library (e.g. Microkernel, Unity, Ninject, etc.)
Modify the server and CCTray to use IoC.

Configure the bug URL builder on ccnetlive.
Move documentation to MediaWiki - this will resolve the reliability problems that Confluence has given us
Spaces instead of tabs - using tabs along with object initalizers and lambdas and other C#3.0 features makes patches less and less readable. A bad thing when our process partly depends on patches.
A clear explanation somewhere in the google groups that messages will need to be approved before they are posted to the group.
Change Source Code Management to Mercurial and BitBucket. Operations against sourceforge's SVN repository are painfully slow. And, I find logs and past diffs to be very important in understanding the code. Having a disincentive to actually use them is a bad combo.
Provide more developer documentation to understand the code. I was thinking "///" class headers to describe the intended responsibility of each class. This would also provide a guide for reviewing other's work, as the reviewer could compare the new code to the class's declared responsibility. Some overall architectural explanation on the wiki would probably be good. Some of the suggested diagrams from Domain Driven Design sound like a good start. How to share these sorts of artifacts effectively over the internet though.

There is currently no planned release date for 1.6, but it a provisional date is 2010.

Please use the Jira issue tracker for consulting the progress, or look for / provide patches.