There was an amazing response to yesterday’s post – not only did readers come up with plenty of names, but lots of people volunteered to help. As a result, I’m feeling under a certain amount of pressure for this project to actually take shape.
The final name chosen is Noda Time. We now have a Google Code Project and a Google Group (/mailing list). Now we just need some code…
I figured it would be worth explaining a bit more about my vision for the project. Obviously I’m only one contributor, and I’m expecting everyone to add there own views, but this can act as a starting point.
I want this project to be more than just a way of getting better date and time handling on .NET. I want it to be a shining example of how to build, maintain and deploy an open source .NET library. As some of you know, I have a few other open source projects on the go, and they have different levels of polish. Some have downloadable binaries, some don’t. They all have just-about-enough-to-get-started documentation, but not nearly enough, really. They have widely varying levels of test coverage. Some are easier to build than others, depending on what platform you’re using.
In some ways, I’m expecting the code to be the easy part of Noda Time. After all, the implementation is there already – we’ll have plenty of interesting design decisions to make in order to marry the concepts of Joda Time with the conventions of .NET, but that shouldn’t be too hard. Here are the trickier things, which need discussion, investigation and so forth:
- What platforms do we support? Here’s my personal suggested list:
- .NET 4.0
- .NET 3.5
- .NET 2.0SP1 (require the service pack for DateTimeOffset)
- Mono (versions TBD)
- Silverlight 2, 3 and 4
- Compact Framework 2.0 and 3.5
- What do we ship, and how do we handle different platforms? For example, can we somehow use Code Contracts to give developers a better experience on .NET 4.0 without making it really hard to build for other versions of .NET? Can we take advantage of the availability of TimeZoneInfo in .NET 3.5 and still build fairly easily for earlier versions? Do developers want debug or release binaries? Can we build against the client profile of .NET 3.5/4.0?
- What should we use to build? I’ve previously used NAnt for the overall build process and MSBuild for the code building part. While this has worked quite well, I’m nervous of the dependency on NAnt-Contrib library for the <msbuild> task, and generally being dependent on a build project whose last release was a beta nearly two years ago. Are there better alternatives?
- How should documentation be created and distributed?
- Is Sandcastle the best way of building docs? How easy is it to get it running so that any developer can build the docs at any time? (I’ve previously tried a couple of times, and failed miserable.)
- Would Monodoc be a better approach?
- How should non-API documentation be handled? Is the wiki which comes with the Google Code project good enough? Do we need to somehow suck the wiki into an offline format for distribution with the binaries?
- What do we need to do in order to work in low-trust environments, and how easily can we test that?
- What do we do about signing? Ship with a "public" snk file which anyone can build with, but have a private version which the team uses to validate a "known good" release? Or just have the private key and use deferred signing?
- While the library itself will support i18n for things like date/time formatting, do we need to apply it to "developer only" messages such as exceptions?
- I’m used to testing with NUnit and Rhino.Mocks, but they’re not the last word in testing on .NET – what should we use, and why? What about coverage?
- Do we need any dependencies (e.g. logging)? If so, how do we handle versioning of those dependencies? How are we affected by various licences?
These are all interesting topics, but they’re not really specific to Noda Time. Information about them is available all over the place, but that’s just the problem – it’s all over the place. I would like there to be some sort of documentation saying, "These are the decisions you need to think about, here are the options we chose for Noda Time, and this is why we did so." I don’t know what form that documentation will take yet, but I’m considering an ebook.
As you can tell, I’m aiming pretty high with this project – especially as I won’t even be using Google’s 20% time on it. However, there’s little urgency in it for me personally. I want to work out how to do things right rather than how to do them quickly. If it takes me a bit of time to document various decisions, and the code itself ships later, so be it… it’ll make the next project that much speedier.
I’m expecting a lot of discussion in the group, and no doubt some significant disagreements. I’m expecting to have to ask a bunch of questions on Stack Overflow, revealing just how ignorant I am on a lot of the topics above (and more). I think it’ll be worth it though. I think it’s worth setting a goal:
In one year, I want this to be a first-class project which is the natural choice for any developers wanting to do anything more than the simplest of date/time handling on .NET. In one year, I want to have a guide to developing open source class libraries on .NET which tells you everything you need to know other than how to write the code itself.
A year may seem like a long time, but I’m sure everyone who has expressed an interest in the project has significant other commitments – I know I do. Getting there in a year is going to be a stretch – but I’m expecting it to be a very enlightening journey.
Jon Skeet's coding blog 
This is what has always keep me from getting anything started. All the extra stuff that isn’t what you are actually creating.
LikeLike
I was certainly considering what level of support for downlevel versions of .Net would be required, and arrived at a similar 2 cutoff. (Are there still people writing 1.x code?)
I think we need to target 2.0 consumer, but could consider 3.5 compiler.
LikeLike
Please *don’t* I18N exception messages. Making an error difficult to find help for only because you have the Finnish version (or a Finnish translation back to English). I know, arrogant English, but it does improve searching.
LikeLike
What about using Codeplex, and TFS for build and test? I know Codeplex also supports SVN, so that could be used if licensing is an issue. If you’re aiming to be the “go to” alternative of DateTime, you’ll at least want a presence there.
LikeLike
A lot of interesting points to consider and I’m sure even more will pop up.
I just started a discussion in the Google Group with my thoughts on some of those questions.
LikeLike
I second NOT I18Ning the Exceptions, If I’m debugging an application to make sure it works in all locales I need to be able to understand the exception messages. If I want to expose a locale friendly message I’ll translate the exception message and expose the translated version when I handle the error.
However, I think it’s important to put sufficient Properties on exceptions such that I can reconstruct an error message in another language if need be.
I’m not doing too much .Net development at the moment and pretty much everything I do is for English speaking customers, but I remember having to check that code worked under the Arabic and Serbian Locale at my last job, if the exceptions were in Arabic I’d have been able to handle it, but not Serbian.
LikeLike
Not being English, I still agree with Damien; exception messages from a library are meant for the developer, not the end users. Keep the library simple and skip translating exception messages.
LikeLike
@Damien: I am Portuguese and I totally agree with you. I hate it when I get exceptions from the framework itself in Portuguese. It doesn’t help at all.
@Timothy: I think it’s already settled to go for hg as the VCS. But I agree we should have a Codeplex presence.
LikeLike
How about PSake for build?
http://tr.im/EmQa
I had very bad experiences with TFS, which of course doesn’t mean TFS is crap. I just felt that it was getting in my way.
Git or HG are the options.
LikeLike
I’m one of the developers of Math.Net Numerics (an open source numerics library for .NET) and I am very very curious to read your guide on how to run and manage an open source project for .NET!
LikeLike
You might want to take a look at the C# code for Fan’s DateTime library. It has full support for historical timezones and DST with a fairly small code foot print.
LikeLike
@Jurgen: Do you have any advice to give us to start with then? :)
@Brian: I’ll take a look, but I suspect Joda provides us with everything we need…
LikeLike
@Cosmin: I really like PSake and I’ve already put it to discussion on the mailing list.
LikeLike
I think targeting the 2.0sp1 CLR using the 3.5 compilers is the best course, preferably in a way that’s mono compatible. The 2.0 CLR is well distributed, having shipped with Vista and Win7 as well as VS2005 and 2008, and is the de facto target for the vast majority of .Net development at the moment.
Also, it might be worth finding a discussion area other than google groups. John Resig has a pretty good critique of their major shortcomings on his blog: http://ejohn.org/blog/google-groups-is-dead/
LikeLike
re: framework versions – If you are planning on a year-long timeline, by the time you get there .net 3.5 SP1 GDR will have been available on Windows Update for nearly two years. I see no reason at this point, for a project such as this, to target anything less than .net 3.5 SP1 GDR.
re: NAnt and MSBuild – NAnt might be getting long in the tooth but only because it is so mature. I wouldn’t let its “beta” nature discourage you.
re: Sandcastle – Please use something with less complexity and creeping dependencies than Sandcastle. Monodoc, Docu, just about anything else would be a step up.
re: low trust – I would assume that the unit test framework of choice would have at least some support for running a test (even if indirectly) in a low-trust setting. If not built-in or otherwise doable, it might suggest a need to evaluate a different test framework or modifications to the one that would otherwise be of first choice.
re: signing – +1 for “public” versus private snk.
re: exception i18n – I agree with the other comments thus far that while end user i18n is one thing, _developer_ i18n is another. It would be best to just punt on developer i18n and declare English as the official developer language of Noda Time, and then provide exceptions (and other developer-specific messages) only in English.
re: NUnit and Rhino.Mocks – NUnit is the defacto standard, so that is a no-brainer. The version of NUnit, on the other hand, needs some consideration. :) Rhino.Mocks has gone through a lot of evolution over the years and as such retains what some might consider to be cruft relative to something like Moq, but at the end of the day Rhino.Mocks still has the strongest feature set. Go with Rhino.Mocks but just put a rule in place that all usage thereof within the project is to use the AAA syntax and style.
re: logging – keep logging out of it. I personally feel that to be too big of a dependency for a library as small as Noda Time to take on. If you feel like you need Noda Time to log, you probably need Noda Time to throw more exceptions.
LikeLike
re: Sandcastle – I’ve had luck with Sandcastle + Sandcastle Help File Builder. The later gives Sandcastle nDoc-like UI and a console app that can be used in the build process. Maybe even MSBuild targets…
LikeLike
Jon.. Skeet…….
I will, hunt you down?
LikeLike
For testing: why not try Gallio+MbUnit?
LikeLike
I recently wrote a WiX 3.0 installer for my own framework addition that provided full integration with Visual Studio, including the Add References dialog and some sample projects. I’d love to help out with that and coding if I’m considered worthy. :)
LikeLike
@Jeff: I’m hoping not to require any installation, but coding is always welcome :)
LikeLike
I was curious about the advantages of Joda Time on DateTime. Net
LikeLike
Is there any thought of a Google Wave associated with the project? It obviously cannot be the primary means of communication, but it seems like software development might be a good fit for Wave’s capabilities.
LikeLike
@Larry: Yes, we’re going to use Wave where appropriate.
LikeLike
I *really* hope you do a blog post on each of the answers to those questions. I don’t really have the bandwidth to follow a mailing list or wave, but I’m very curious about the options and what you go with and why.
LikeLike
Thanks for pulling this together. I think I’m interested in the meta questions about OSS in .net than anything else. Looking forward to watching this play out.
LikeLike
I few thoughts of the top of my head…
You say “In one year, I want this to be a ….”
Therefore witch versions of the .NET framework will your users be on in one year time? Given that Noda will most be use on project that are skill actively being developed, I think aiming for .NET 3.5 will be about right.
If Noda can work with the .NET V2SP1 framework so match the better, however there is no need to allow Nada to be compiled with the C# 2 compiler.
Support for Code Contract would be great, as there will need to be a lot of augment checking code for .NET 3.5 (and before), I think some sort of code generator (or preprocessor) is needed so that all the “arg1 not null” logic does not need repeating.
The code contract post conditions and more detailed pre-conditions can just be done by #ifdefs. It would be great if the *important* Code Contracts were used to generate some of the API docs.
LikeLike
@Ian: Yes, we’re not trying to compile with the C# 2 compiler. .NET 3.5 is a minimum for building.
LikeLike
“Do we need any dependencies (e.g. logging)?”
none whatsoever.
There should be no reason for this (release) code to take any dependency on anything else. It is the very shining example of a leaf node.
It should not log, because either things are correct (so why bother) or they are wrong, in which case it is an exception. Nothing in the library should ever allow as wishy washy state of error/ok.
Diamond Dependency issues are a massive PITA with no clean solution (forcing things into the GAC isn’t clean).
LikeLike
@Tony the Pony:
Why .Net 3.5?
I think something like this can be done in .net 2.0, obviously using c# 3.0 compiler (for extension method and sugars), just don’t reference System.Core ;)
Btw, Using Mono’s System.Core should build flawlessy, but I didn’t check it myself.
(Personally I develop targetting 3.5 and switch-ing back to 2.0 removing System.Core and if needed adding linqbridge)
I think that targetting .net 2.0 is a good start if you really want to support CF…
LikeLike
@kentaromiura: If you’re going to require the C# 3 compiler, then you’re building on .NET 3.5 anyway, as I said… but we’ll be targeting .NET 2.0 for the main library itself.
The unit test library (etc) will probably target 3.5.
LikeLike
Probably I’m not explained correctly, but the fact is that you can use c# 3.0 compiler (lambda expression, extension method) and target 2.0.
Since probably I can’t explain it well, see
http://www.albahari.com/nutshell/linqbridge.aspx
to understand what I mean.
BTW, if the main library is targeted to .net 2.0, than there is no problem :)
LikeLike
@kentaromiura: Where do you intend to get the C# 3.0 compiler from if you’re not running .NET 3.5?
I think you’re asking for what I’ve been saying all along: build on .NET 3.5 (which makes the C# 3.0 features available) and target 2.0.
LikeLike
LOL! Sorry for the misunderstanding,
when I read “.NET 3.5” on comment #1738559 I mentally associate it with System.Core, that is not compatible with .NET 2.0 .
English is not my first language and the tiredness drive me in error ;)
LikeLike
Rather than using NAnt-Contrib, we use NAnt’s built-in exec task to call MSBuild.exe. To get the path:
framework::get-framework-directory(framework::get-target-framework())
Please consider taking a look at Moq before standardizing on Rhino.Mocks. http://code.google.com/p/moq/
And thank you!
LikeLike
@Bill: Hmm… any reason *not* to use NAnt-Contrib, and get a more readable build file? Not that we’re settled on NAnt.
As for Moq – that’s certainly one of the mocking options, although currently we suspect we may not need a mocking framework at all.
LikeLike
Will noda time support mayan calendar dates beyond 2012?
LikeLike
@Mayan Mike: If and only if Joda Time does :)
LikeLike
Noda ( 野田 ) is a Japanese surname as well.
LikeLike
I have faced (and I’m still facing) the very same questions on OpenTK, a cross-platform Mono/.Net binding for OpenGL and various other APIs (http://www.opentk.com).
Several of those issues involve trade-offs, one way or another. For example, using msbuild directly will result in problems once people start upgrading to Visual Studio 2010 (which has a different file format). To avoid this issue, OpenTK relies on Prebuild [1] to generate msbuild and nant build files from an XML description.
An interesting tidbit: xbuild is now working pretty well on Mono, so you can avoid nant completely if you wish.
For documentation, MonoDoc is by far the best solution. The alternative, Sandcastle won’t run on Mono and is generally ugly (which means that you’d restrict your build environment to Windows). Unfortunately, MonoDoc isn’t without issues either: it depends on GTK# (no problem on Linux, but it’s an additional dependency for Windows and Mac OS X); it also requires you to keep documentation outside your source code (yes, in theory it can use XML doc comments but this doesn’t really work in practice – the resulting documentation will be missing descriptions and will be unusable).
Regarding runtime support: binary serialization between runtimes is the sticky point here (and a place where your project can shine – note that System.DateTime is not serializable between .Net and Mono). It would also be nice to support the MonoTouch runtime (Mono on the iPhone) – the main limitation is the lack of dynamic code generation (if you were planning to use this).
LikeLike
A couple of thoughts:
Although I still develop on a few applications which target .NET 2.0, that is only because they are in maintenance mode and we are not making major changes. Anything that is experiencing a major change gets upgraded to 3.5 SP1 w/ GDR. Integrating a third-party time library is not something that will be done lightly, and therefore is not likely to be done for apps in maintenance mode. So I am not sure of the value of targeting 2.0 at all.
What is the advantage of using NAnt AND MSBuild? There is a huge amount of overlap there, and I would think using one or the other (probably MSBuild) would make things a lot less complicated.
I agree with Shuggy that every effort should be made to make this a leaf node with no dependencies. Logging is an application concept and does not belong in a library; all the library has to do to support logging is expose state, events, and exceptions.
LikeLike
It would be wonderful to have lunar calendar support.
LikeLike
@Guangwei: The Hijri calendar is lunar – did you want anything beyond that?
LikeLike
I suggest doxygen for code documentation. It has the advantage of being comment-compatible with javadoc…
Also I wonder if English-only exceptions isn’t the wrong way to handle the search concern. How about numbered exception prefixes (NODA001: February hasn’t got 34 days) just like the compiler has? This way the correct search keyword is immediately obvious and not likely to return false positives.
LikeLike
I ‘m recent undergrad, never done open source project, this is the first one i want to follow to learn how things work. Thank you for doing this stuff..
LikeLike
I’ve been following for some time your progress on porting this Joda Time library.
However, as someone who didn’t use Joda Time, I didn’t quite get why this library is better than the normal DateTime stuff in .NET.
I mean, you’ve written a lot about Noda Time, but I think it would be helpful to make somewhere a clear Statement about what problems will Noda Time solve / which use-cases will be simplified.
(you might have written about it somewhere, but I didn’t manage to find it)
LikeLike
@Dan: No, I haven’t written about that yet, but I shall do so at some point. I just need to find the time :)
LikeLike
A bit off topic; but
why are so many willing to help Microsoft hijack everything that been done in Java?
Don’t you get a creepy feeling about “porting” other developer’s hardwork onto a commercial platform?
LikeLike
@Sam Winston: In what way is Microsoft “hijacking” anything? They’re doing nothing to stop you from developing in Java should you wish. It’s not like Java was a completely new idea which didn’t build on ideas which had come before it, either.
And no, I don’t have a creepy feeling about porting the work of other developers. Heck, Stephen Colebourne himself is a member of the mailing list and has given us plenty of good advice.
Frankly, if someone wanted to make sure their work wasn’t ported to another platform, I’d expect them either to not release the source, or to release it under a licence which prohibited it.
Finally, I regard Java as a commercial platform too. Sure, it’s open source – but it wasn’t for a long time. Note that you can develop on both Java and .NET without paying any licensing costs.
LikeLike
Oh my, I think I’ll feed it…
What do you mean commercial platform?
.NET is not sold.
It is based on open ECMA standards.
Even though Microsoft’s implementation is not, there are open-source implementations, like Mono which we do intend to support (you would know that if you had read Jon’s post carefully).
If you mean that .NET is used on commercial stuff, so is Java, so is Ruby, so is everything that does not carry an explicit non-commercial license.
JodaTime is licensed under an open-source license, meaning it’s to be *shared*. NodaTime is released under the same license, so it’s not “commercial”. That’s what open-source is about: *sharing*. Not some sort of fight against someone’s perceived enemies.
Imitation is the ultimate compliment.
We are not doing this for Microsoft. We are doing this for the community.
Stephen Colebourne, the developer whose hardwork we’re “hijacking” has nothing against it. He is even helping us. And, in the end, it will be our hardwork too.
Questions?
LikeLike