I realize we’re a bit late in releasing a version for Studio ’08. Now you might say to yourself “how hard can it be? Just open the solution in Studio ’08, let it upgrade, recompile and release.” Sure, it could be that simple if we wer content with just tossing it out there, but we’re not. With the move to Studio ’08 we decided to take advantage of some of the new tools we have. First we migrated the entire SDF source tree from Vault to TFS. Vault worked just fine, but we wanted to take advantage of TFS and integrate both continuous integration, automated testing and test-driven development into the product.
That mean rearchitecting the solution and projecy layouts and then writing tests. Lots of tests. Of course writing tests leads to finding bugs, which then leads to fixing bugs. We started by looking at reported bugs but also looking at some use cases and testing classes we know get the most use. We have no delusion that we’re going to have even close to full code coverage (or even 50%) by our next release, but we want to get off on the right foot and at least have some coverage for the next release.
Of course we’ve also added some new features like the OpenNETCF.Net.Mail namespace and all of this takes time. As of right now we have less than 40 hours of test writing left to hit our release milestone. Once we hit that, we then have to build the Help and installation package and release. My hope is to have something ready in early September, but that’s not a guarantee. We know you want the release – we do – we just want to make sure it’s right.
An ancillary question that also comes up is “when will we be releasing a version compiled for CF 3.5?” As of right now we have no plans to release a CF 3.5-targeted version of the SDF. Yes, you read that right. We have no plan for a CF 3.5 release. “Why is that?” you might ask, after all CF 3.5 is the latest and greatest, right? Sure, it is, and we think that when possible you should use it. However the SDF has historically been used by developers using older versions of the CF and is already rolled out in a *lot* of CF 2.0 projects. If we moved to 3.5, none of those 2.0 project would be able to use the SDF without recompiling themselves. If we moved to 3.5, then we’d also be tempted to use 3.5 features, which would then even make the source incompatible with 2.0 and a recompile wouldn’t even be an option. I, for one, don’t really want to leave all of those CF 2.0 developer’s high and dry.
Since CF 3.5 assemblies are unusable in CF 2.0 projects, but CF 2.0 assemblies can be used without a problem in CF 3.5 applications it makes the decision pretty simple. If we stay with CF 2.0 as a target, then far more people can use the library. If you absolutely must have it built targeting CF 3.5, you can always recompile the source yourself.