WCF Data Services, now with more releases!

  • [アーティクル]

Like other teams at Microsoft, WCF Data Services has been working toward a goal of more frequent releases. We released 5.0 on April 9 and we pre-released WCF Data Services 5.0.1-rc* on April 20 (we’ll release the final version of 5.0.1 very soon). The rapid release was possible because of three changes we’re making. First up, we’re…

Adopting semantic versioning

Semantic versioning is a growing movement that proposes a solution to confusing version numbers. Let’s see how semantic versioning applies to the pre-release: 5.0.1-rc.

  • The first digit is the major version. Semantic versioning states that the major version should be bumped only when there are breaking changes in a public API.
  • The second digit is the minor version. Semantic versioning asserts that the minor version should be bumped when new functionality is introduced to the public API.
  • The third digit is the patch version. Semantic versioning says that the patch version should be bumped for bug fixes that do not affect the public API.
  • The hypenated string is the pre-release version. Semantic versioning claims that the pre-release version should be appended to anything that is not a release.

Since 5.0.1 only contains bug fixes, we bumped only the third digit of the version number. The prerelease that went out on April 20 was suffixed with -rc to indicate that the bits are not yet release quality.

* Note: When we initially pushed out the prerelease, we thought we would need the minor version increment. This turned out not to be the case, so we fixed the version number to be the correct value according to semantic versioning. We hid the 5.1.0-rc prerelease today, replaced it with 5.0.1-rc and will release the final bits as 5.0.1. If you have installed 5.1.0-rc, you’ll need to uninstall that package before you can install 5.0.1-rc or 5.0.1.

Moving to semantic versioning facilitates our decision to…

Distribute new releases via NuGet

NuGet is a fantastic binary distribution system for a number of reasons. NuGet enables us to release more frequently without causing additional confusion – the version history on the package page clearly displays the versions that have been released:

image

NuGet also makes it easy to take a dependency on a particular version of an assembly with commands like Install-Package Microsoft.Data.Services.Client –Version 5.0.1. Furthermore, NuGet makes it very easy to recognize prereleases and even provides a special version of the command line that support prerelease versions:

image

NuGet also makes it easier for us to achieve a third goal…

Changing to a “bin deploy” model

If you’re not familiar with the term, a bin deploy model is one in which you simply copy the contents of the bin directory to the target location – there are no MSIs involved, no GAC – just DLLs and your preferred file transfer mechanism.

There are many reasons to move to a bin deploy model. Two of the more obvious reasons are:

  1. A bin deploy model simplifies deployment and increases the number of potential deployment targets. You don’t need your Web server to run a particular MSI that puts the appropriate assemblies into the GAC. This opens up a whole host of scenarios, including deploying OData services to hosting providers that won’t run the WCF Data Services MSI. It also increases confidence that when an application is deployed, it has all of its dependencies readily available.

  2. A bin deploy model allows trust levels that are commonly leveraged by hosting providers.

We’ll be writing more about NuGet and bin deploy in the near future, but for now we would love to hear your…

Feedback please!

We’d love to hear what you think about 5.0.0, our more frequent releases, and our changes to distribution/deployment. Feel free to leave a comment below!

Comments

  • Anonymous
    May 07, 2012
    To help avoid confusion, IMHO you should update the sshots with the 5.0.1-rc.  Otherwise, people just skimming will get confused when they go to install it.

  • Anonymous
    May 07, 2012
    There's also a good versioning lesson here.  If you're not sure whether you need to update the minor or not, then don't at first.  If it turns out you do, then no big deal.  Once you start going backwards (like here), then you break the versioning story.  Hopefully NuGet doesn't end up needing to go down the road of other package management systems (like rpm, dpkg, etc) of adding an 'epoch' (effectively, override) that increments for such situations.

  • Anonymous
    May 07, 2012
    @James - Screenshots updated, and we hear you on the versioning lesson. I'm sure we'll have a few missteps but hopefully we're headed in the right direction.

  • Anonymous
    May 08, 2012
    Is there any chance that you guys could make ObjectContextServiceProvider public? I'd like to be able to implement as version that can handle EF5's Enum support, but I can't inherit from it to be able to do my work. Thanks!

  • Anonymous
    May 17, 2012
    The comment has been removed

  • Anonymous
    May 21, 2012
    Hi Mark, It there any documentation/source/tests available for recently uploaded OData NuGet packages? Especially for packages used internally by Data Services such as Microsoft.Data.Edm or Microsoft.Data.OData.