Let me know what you think. We should discuss here on the mailing list
to get the best exposure to the current maintenance team. I'm guessing
I should make the changes on a branch, with 1.5 coming up soon.
I have been thinking about backwards compatibility. I'm not keen to
update all the sourcecontrol providers myself! I'm hoping that by
having any new objects implement interfaces that are compatible with
the old objects, and by using adapters, this can be introduced without
*requiring* changes to any existing custom code. In other words,
hopefully it can be an opt-in thing to be implemented where and when
it makes sense to. More on how I think that can be accomplished in the
next blog post...
I had not considered people subclassing Modfication. That is an
important thing to consider though. I had always thought that the
Modification returned from the SourceControl implementation should
be preserved, but I thought it might be copied around a bit.
Subclasses suggest it should be preserved absolutely as-is, as far as
To be honest I am not completely sure. I was hoping to hear back from
Ruben, Craig and so on about that. I was interpreting the CTP as an
indication that a final release from that code-line was the next goal.
Changing central parts of the object model wouldn't seem to move us
towards that goal!
Yes, we are trying to stop new features and focus on getting
CruiseControl.NET 1.5.0 ready for a formal release. We need to do a SP2 for
1.4.4 to tidy up a couple of critical issues that were found after the
release. Hopefully, we'll also be able to release the CTP of 1.5.0 around
the same time - but that more depends on when somebody can do the actual
Yes, there are a number of significant changes from 1.4.x to 1.5.0, but most
of them do not affect the core functionality of CruiseControl.NET. Where
possible, we have tried to not modify the interfaces, so hopefully all that
is needed is to recompile your extensions against the new 1.5.0 binaries and
all should be good - with maybe one or two exceptions (like we changed
LastChangeNumber on IIntegrationResult from an int to a string).
Are you able to try and compile your extensions against the 1.5.0 binaries
and tell us of any errors? Otherwise, it is going to be challenging to try
and find all the breaking changes :-(
There was some discussion around whether the next release would be 1.5 or
2.0, but no formal decision was made and most people were calling it 1.5, so
that's the label that stuck.
From: ccnet...@googlegroups.com [mailto:ccnet...@googlegroups.com] On
Behalf Of David Cameron
Sent: Wednesday, 8 July 2009 4:19 p.m.
Subject: [ccnet-devel] Re: a blog post from me about refactoring
I've made the first set of changes on a branch in Mercurial.
(Subversion is pretty much unusably slow these days for me.)
I have blogged about the changes at:
And the changes themselves are visible on bitbucket:
In terms of backwards compatibility, implementers of ISourceControl
would need to change the signature of their GetModifications methods.
Everything else could stay the same at this point.