Since .NET 4 was released Microsoft has been pushing an ever faster release cadence for its .NET libraries with new features coming out every few months instead of every few years like it had done in the past. While moving away from “big bang” releases is welcomed by many, there have been complaints that they are going too far in the other direction. Of particular concern is ADO.NET Entity Framework, the ORM being positioned as the definitive replacement for all other .NET based database access technologies.
The story begins back in July with the release of Entity Framework 4.1 Update 1. This was a very small release with a minor bug fix and some minor helper classes to facilitate design-time tools. At the time we didn’t even feel like it was worth reporting on and like most we pretty much ignored it. That is, until the tool vendors started complaining.
As reported by Frans Bouma, a bug in an internal function GetProviderInvariantName causes Entity Framework to fail when working with a DbProviderFactory that happens to be generic. Since Update 1 didn’t have a public beta, no one found out until it was already in production use. This primarily affected ORM profilers; Frans explains,
As you might know, we've been busy with our own data-access profiler for a while now. The profiler, which can profile any DbProviderFactory using data-access layer / ORM, works by overwriting the DbProviderFactories table for the app-domain the profiler is used in. This is a common technique: it replaces the type name of the DbProviderFactory of an ADO.NET provider with the type name of a wrapper factory, which receives the real factory as a generic type argument. Example: ProfilerDbProviderFactory<System.Data.SqlClient.SqlClientFactory>.
This is the same technique used by the Hibernating Rhino's profilers and others, and it has the benefit that it's very easy to use and has no intrusive side effect: you only have to add 1 line of code to your own application and everything in the complete application can be profiled.
In response to this embarrassment the ADO.NET team has promised to go back to releasing betas for even small releases. The beta of EF 4.2 should be out sometime this week via a NuGet package.
Entity Framework is also adopting the concept of Semantic Versioning. The goal of semantic versioning is to make version numbers actually meaningful. With semantic versioning we wouldn’t have seen a handful of libraries being branded as “.NET 3.0”, a major version of Visual Studio labeled “.NET 3.5”, and another set of major libraries introduced as “.NET 4.0 Service Pack 1”. There are numerous rules to deal with beta and pre-release versions, but the core concepts are:
- Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
- Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes.
- Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes.
