EF Releases & Versioning - Call for Feedback

 


The information in this post is out of date.

Visit msdn.com/data/ef for the latest information on current and past releases of EF.


 

The EF team has been working toward being more agile and having a higher release frequency. We are also releasing more previews and making them available earlier in the release cycle so that your feedback can help shape the product. This effort has seen us publishing a much higher number of releases.

In the last 6 months we have released; EF 4.1 Release Candidate, EF 4.1, EF Power Tools CTP1, EF June 2011 CTP, EF 4.1 Language Packs, EF 4.1 Update 1 and Code First Migrations August 2011 CTP. That is a pretty confusing list of releases, especially given there are some incompatibilities and dependencies within the list. Just to add to the confusion each release is available in one or more places including Microsoft Download Center, NuGet & Visual Studio Gallery.

It’s become clear that we need to rationalize how we name, distribute and talk about releases. This problem isn’t just affecting our team, Scott Hanselman recently posted about the need for better versioning across all our products.

This post will walk you through the changes we are planning to make. Nothing is locked in yet so we welcome your feedback.

 

What We Ship

There are two logical parts to the Entity Framework, the core components that ship inside the .NET Framework and Visual Studio and the ‘out of band’ components that we can update on a much more frequent schedule. We are currently looking at how we can update the core components on a more frequent cadence as well. The ‘EF June 2011 CTP’ was our first attempt at shipping the core components more frequently and it’s become clear we’re just not technically ready to do this yet.

Core components include:

  • Core EF Runtime (System.Data.Entity.dll & System.Web.Entity.dll)
  • EF Designer

Out of band components include:
(We will likely ship more out of band components in the future)

  • The DbContext API & Code First (EntityFramework.dll)
  • T4 Templates for using DbContext API with Model First & Database First
  • EF Power Tools
  • Code First Migrations

 

Where We Ship

As mentioned above, the core components will remain part of the .NET Framework and Visual Studio.

The out of band components will be primarily available via NuGet and Visual Studio Gallery.

  • The DbContext API & Code First will continue to be available as the EntityFramework NuGet package. We no longer plan to provide a stand-alone installer for these components. If you want to GAC or distribute the EntityFramework assembly it can easily be taken from the NuGet package.
  • T4 Templates for DbContext API will become available on Visual Studio Gallery. In the past we have distributed other T4 templates, such as our POCO templates, using this mechanism.
  • EF Power Tools will continue to be available on Visual Studio Gallery.
  • Code First Migrations will continue to be available via NuGet. We will likely also release via another mechanism to support team build and deployment scenarios, we are still working through the logistics of this.

NuGet will eventually have built-in support for pre-release versions of packages but in the meantime we will introduce a .Preview version of each package. For example the EntityFramework package will be the latest fully supported runtime, EntityFramework.Preview will be the latest preview. For the period between an RTM release and the next preview both packages will include the same build. We will ensure that the non-preview packages always work together (i.e. EntityFramework will always be compatible with EntityFramework.Migrations etc.). We will try to ensure that the latest pre-release versions work together but this may not always be possible.

 

Version Numbers

The version numbers of the core components will be governed by the .NET Framework & Visual Studio release that they are part of.

For our out of band components we will version using principles from Semantic Versioning.

  • The DbContext API & Code First is currently at 4.1.10715.0 and is called ‘EF 4.1 Update 1’. The next update to this package will bump the version number to 4.2.0 and be called EF 4.2, we will follow semantic versioning from that point forwards. At this stage EF 4.2 will just include some bug fixes. This is the primary out of band component and we will use its version number to describe what version of EF is the latest (i.e the next release will be EF 4.2).
  • T4 Templates for DbContext API are currently included in the EF 4.1 installer. We will move these to Visual Studio Gallery with a version number of 1.0.0 and follow semantic versioning from that point forwards.
  • EF Power Tools are currently in preview mode and available on Visual Studio Gallery with a version number of 0.5.0. We will continue to follow semantic versioning with this component.
  • Code First Migrations was initially released on NuGet with a version number of 0.5.10727.0. The next preview will be 0.6.0 and then we will continue to follow semantic versioning with this component.

Once a component has had an RTM release (i.e. reached version 1.0.0) all subsequent previews will use the target final release number with an ‘alpha’, ‘beta’, etc. special version. For example we will release EntityFramework.Preview package with a version number of ‘4.2.0beta1’ before releasing EntityFramework with a version number of 4.2.0.

 

Please let us know what you like and what you think we should do differently.

Rowan Miller
Program Manager
ADO.NET Entity Framework

Comments

  • Anonymous
    August 10, 2011
    I like it. Definitely a step in the right direction.

  • Anonymous
    August 10, 2011
    Using Semantic Versioning is a great move.  It's going to make my life easier, that's for sure. Narrowing down to NuGet and VS Gallery as the methods of distribution is a great improvement over how it has been  (e.g., NuGet, VS Gallery, MS Download, Codeplex, etc.).  I don't know if it's technically possible, but narrowing down to just one would be awesome.

  • Anonymous
    August 10, 2011
    That sounds great!  Much easier to understand.  I wish more teams at MS would adopt something similar.

  • Anonymous
    August 10, 2011
    One step in the right direction. Let's hope there are more.

  • Anonymous
    August 10, 2011
    Wait, how does that affect the package that is currently referred to as EF 4.2, which is the EF version with Enum support?

  • Anonymous
    August 10, 2011
    You can't release EF core like ASP.NET MVC team does? A ORM framework needs a much more frequent releases that .net framework

  • Anonymous
    August 10, 2011
    Robert, I think that if EF June 2011 CTP will be EF 5.0.0 then next release should  be 5.0.0alpha

  • Anonymous
    August 10, 2011
    The comment has been removed

  • Anonymous
    August 10, 2011
    The comment has been removed

  • Anonymous
    August 10, 2011
    @Felipe Fujiy - No that's a bug we introduced in the EF 4.1 Update 1... that is one of the reasons we want to get our version story locked in and get another release out that fixes that bug.

  • Anonymous
    August 10, 2011
    Any move towards more NuGet distribution and less MDC downloads is a good thing!

  • Anonymous
    August 10, 2011
    Please make the entire Entity Framework a out of band release. There is really no need for it within the core .NET library, and it will allow more frequently updates to Entity Framework.

  • Anonymous
    August 10, 2011
    Martin, I created a suggestion at data.uservoice.com/.../2140735-entity-framework-assemblies-out-of-net-framework You can vote. I have this one too. Many people dont see the problem because dont profile application, but is much important: data.uservoice.com/.../1050591-extra-lazy-loading

  • Anonymous
    August 11, 2011
    I think the "where" part of this has some real problems still. Stuff is scattered among multiple places and it's not straightforward to figure out what you need for a given project. Lets say for example someone is using DB First with the Dbcontext API (which is exactly what I'm doing on my current project). Last time I grabbed the standalone installer from the Microsoft download page, installed it, and I was good to go. For anyone else on the project? Same thing. Get this one thing, and you're done. Now? Well first of all I need whatever the current core version is, assuming it's not the same one that shipped with .net 4 itself (I think it is right now, so assuming that never changes I'm okay). Then I need the EntityFramework package from NuGet. Then I also need the templates from the Visual Studio gallery. Instead of one download on one site, I need at least two downloads from two different places. Most likely I'll need to go to a third page first that tells me where I need to look in order to get those two pieces, because I'm probably not going to remember (and someone just starting with EF is never going to find it all on their own).  And I'm not clear on how template updates will be handled because I've never updated anything from the VS template gallery before. Is that automatic? Will EF 4.2 realize there's a 4.2 template that should be updated as well? What has to be done here?

  • Anonymous
    August 12, 2011
    I'm wondering why with the exception of the Power Tools you don't just bundle everything into one package? For example, is it really necessary to separate out the T4 Templates for DbContext API from the DbContext API itself? It seems confusing to have to install several different packages which all don't seem that big. It seems like it would be easier to just have one package and only have to do a single install. I'm definitely for making it so that EF core can be updated frequently and not be tied to the release of the .NET Framework itself.

  • Anonymous
    August 15, 2011
    The comment has been removed

  • Anonymous
    September 02, 2011
    when insert a record with autoincreament identity.  entity framework use 2 sql: insert Rolesvalues (@0); select [ID]from [Roles]where [ID] = @@IDENTITY   the 2nd sql is ugly,why don't SELECT @@identity as [ID] thanks for your great jog.