OSS and the .NET Framework upgrade

I’ve hit a bit of a dilemma recently, I want to use features in C# 4.0 and .NET 4.0 to enhance AutoMapper, but this would eliminate the possibility of .NET 3.0 projects from being able to use the new version.

One option is to say that the current version is the last 3.0 version, and if you want 3.0, use that one.  Another option is to fork, and keep a 3.0 version going forward, where I can apply bug fixes etc. to it.

This is the first OSS project I’ve been involved in that actually survived to another .NET Framework release, so I’m not entirely sure what the community expectations would be around this area.

My initial thought is just to upgrade the library to VS 2010 and .NET 4, but that might leave a few people in a lurch.  Luckily I’m on Git, so it’s not really a problem to support multiple branches.

How have other projects dealt with this?

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Keep in mind that at the very least you can upgrade the solution to VS2010 and downcompile to 3.5. You could even be nice and include a simple build.bat file that executes msbuild against the solution so that those without VS2010 could still compile it (something I find convenient either way – I’d prefer to not have to open VS unless I’m actually going to edit something).

    That said, my vote is to mark the current version as the last one on 3.5 – it is pretty darn useful as is – and continue forward with 4.0 only.

  • Go ahead and fork. The 3.0 version will get bug fixes only. The 4.0 will get bug fixes and any new features.

  • Definitely fork it. 3.0 will exist only for bug fixes.

  • I vote to fork it and let the version 3.0 be maintained by the community, this way bug fixes can be integrated and someone can port new features from the version 4 to the version 3.

  • Henning Anderssen

    Fork and bugfix existing version and all new development should be on .net 4.0

  • Jason Meckley

    I’m one of the VS 2008 .Net 3.5 devs. The same conversation just arose regarding the Rhino stack. A Fork for 3.x seems to be the common solution.

  • I seems that Moq handled this with multiple versions:


  • phil

    get a fork’n move on.

  • Jeremy

    Branch it, so at least it will use the right terminology. :)

    In all seriousness, I truly doubt that forking it, whether in the Git interpretation of the word or not, is what you or any of the other commenters intend. Do you really want to maintain it as two separate repos? Or, more likely, as two branches in one repo.

  • Do what castle do and have a VS2008 solution and a VS2010 solution.

    Use the framework version as a switch to what is getting built.

  • @Jeremy

    Branching it :)


    I’m not sure that fixes the .NET 4.0 vs .NET 3.5 issue, does it?

  • Chris Sutton

    Take full advantage of .NET 4 on the main branch and just provide fixes for the VS 2008 version.

  • I’d go for the branch myself. I think the uptake on 4.0 is much smoother than say 1.1 to 2.0-3.5 for the most part everyone I know is at least researching the move at this point and plans to do so by end of year… as long as going from the 3.x version to the 4.x version is relatively smooth it should be fine… just try not to break anything (change too much) for the next year or so… adding stuff is fine though.

  • Jon

    Yep, go with the branch/bugfix only option for VS2008/.NET3.5 and move onto VS2010/.NET4.0 asap.