Anson and i had a pretty interesting argument about the need to ship working versions of the tools with the platform we’re releasing. His take on it was that when a new platform shipped we had to provide tools that worked with it at that moment. i.e. compilers/debuggers/IDEs/etc. all had to use and understand the new platform. My take on it was that it would be better to have the platform finally stabilized and to then release the toolset a few months later. This would reduce the amount of churn that happens, say, when the runtime changes how generics are represented, or when the language team changes the semantics/language features of the C# language. IMO there is an immense amount of wasted effort when these changes come around because very often you find that most (or all) of the work you’ve done so far needs to be redone. By waiting until they were stabilized we would reduce this wasted time because we wouldn’t experience (all of) these pains as the platform moved forward.
However, after my experiences today I have to admit I see where anson is coming from. Because NUnit the toolset gets updated and released after the platform i shipped. However, this means that internally if we want to use this great tool we can’t because it limits us to the last shipped version of our platform. So i can see the necessity for not only shipping the toolset with the platform, but also keeping the toolset maintained as the platform evolves.
However, I’m stuck in a rather unfortunate position here. I need a unit testing engine and I don’t have one. I could use the one I wrote a year ago, however I’m worried about that as i am then dependent on my unit testing engine being relatively bug free. I definitely feel that i need to be bootstrapping here, I just don’t know how.