Jul 14

Written by: Rodney Joyce
7/14/2006

The more technical amongst you may know that the reason there are 2 core version of DotNetNuke (3.x and 4.x) is because of the underlying .NET technology. DNN 4.x runs on Visual Studio 2005 and .NET 2.0 (includes C# 2.0 and ASP.NET 2.0) and was released last year in November. DNN 3.x runs on the old Visual Studio 2003 (looking somewhat dated now) and .NET 1.0.

There are some major changes in the compilation models and hence the project/solution layouts, but this is beyond the scope of this blog. Basically the DNN core team feel it necessary to support 2 distinct codelines for legacy reasons and also to keep moving DotNetNuke forward on the latest technology. I agree with this strategy (after all, a lot of us are depended on our Hosting Providers as well as financial and other indirect costs), and an upgrade to DNN 4.x is not always feasible or possible. Having said this, it must be understood that this is a massive drain on resources (consider that even with the most productive tools, 2 separate lines of code must be maintained, developed, tested, QA’d and released. While not quite doubling the resources required, there is definitely a massive disadvantage to doing this and something else suffers to achieve this.

My personal view is that the sooner the core drop new versions of 3.x the better. Before you burn me at the stake (all my websites, including Smart-Thinker and PokerDIY.com are in 3.x still by the way), hear me out.

The core can still release minor updates and bug fixes for show-stopping bugs in 3.x. Once DNN 3.3.x is out and is Gold (3.3.2 – the current version at the time of writing, is a Release Candidate only and should NOT be used on live sites), then this is a very functional DNN version and I believe all efforts should be focused on DNN 4.x only. This will increase productivity massively and ensure the DNN project keeps (and gains) momentum. Users of 3.x can either choose to stay on the current version (if it suits their needs – that should not be a problem then), or can upgrade when ready (feasible or possible). If a showstopper bug appears in 3.x then minor updates can be released (probably for the next year or so – it does not make sense to do this indefinitely as resource and the codebase will have to be maintained. Please note that I have no more inside knowledge of the core workings than you – these are merely my own personal opinions on how I feel the project should move forward gracefully.

This is also the Smart-Thinker strategy for our modules and moving forward with DNN and our module product suite. As a small team, we simply do not have the resources to maintain 2 distinct lines of code and back port (from a technical POV, this is what you need to do – you can’t simple upgrade or share the code – they have very different compilation models and architectures) code to the 3.x versions. It is essential that everyone can use the Smart-Thinker product suite, so all existing modules will continue to be supported until we have no more 3.x customers left (this is the key bit). New modules, for example, the Smart-Thinker Scheduler – more on that later, will ONLY be released in 4.x and will not work on 3.x. I apologise now if this offends anyone, but the time and effort to work on the same product twice means other areas of growth would stagnate and this would not be good in the long run. I’ve already had a lot of requests from our Gold Developer subscribers for the source code in 2005! (Most modules are sill in the 3.x version as they are compatible with 4.x, but this means you are not getting any of the advantages of the .NET 2.0 framework – the main one being a proposed 70% less code and increased productivity in Visual Studio 2005. This means tighter code, more releases and better modules for you.

Which brings me onto another topic: development standards. Recently I have personally been tightening up our development process with VS 2005 which should become apparent in the higher quality of Smart-Thinker modules over the next few releases. We are in the process of implementing Virtual Server and Virtual PC (this makes testing a lot easier as you can setup machines in various states and test certain scenarios and then roll them back with ease), 2005 Unit Tests (similar to NUnit, but integrated into the VS2005 IDE), continuous builds, Team Foundation Server (better source control, development process etc). Hopefully all of these changes will be apparent to you as the end user and will allow us to increase productivity and output. In the last few months we have been waiting for the core team to make their move and now that this is done we can start gearing up for some good development.

According to our recent survey (http://www.smart-thinker.com/Other/Surveys/tabid/1095/Default.aspx) which over 275 people took part in, 190 of you are using DNN 4.x and the roughly other 1/3 of you are using DNN 3.x. Considering the amount of people waiting for the DNN 4.3.x Gold version, and it’s safe to say that the overwhelming majority of the community are using or about to use DNN 4.x

I’m interested to hear the DNN communities view on this – please let me know what you think.

Next blog… Module Updates…

Copyright ©2006 Rodney Joyce

Tags: