Late in November, the Azure Storage team announced an update of the Storage Library that corresponds with the “2013-08-15” Storage API update. They weren’t explicit about it in the release post, but this was a major version upgrade to Azure Storage SDK 3.0. The 3.0.2 Storage SDK is not part of an official Azure SDK release, the Azure 2.2 SDK officially shipped with Azure Storage 126.96.36.199 (release notes). I expect the next Azure SDK will include this Storage SDK (or perhaps a 3.1 version, depending on timing).
The Azure SDK is composed of a number of different assemblies and projects that are versioned independently. The Azure API has been updated annually for the last few years, the latest version being “2013-08-15”, a yyyy-MM-dd value. The Azure Storage SDK for .Net split from the main versioning between SDK 1.7 and 1.8, going from 1.7 to 2.0. The Azure ConfigurationManager assembly is currently on 188.8.131.52-something, is listed in nuget as 2.0.3, has a file version of 184.108.40.206, and is part of Azure SDK 2.2. I haven’t looked at the node, java, etc projects and have not looked terribly closely at the the rest of the assemblies that make up the .Net Azure SDK.
I’ll try to be clear which thing a version applies to as the post progresses.
Besides the confusion of mismatched version numbers, this version of the Storage SDK was released without local development (emulator) support. When released, there was no emulator support for “2013-08-15”, however a preview version of the emulator has been released now, for those of us that depend on local development.
Azure Storage SDK 1.7 (Silently?) Deprecated
The 1.7 version of the sdk has been silently deprecated. I initially thought I missed the announcement in one of the SDK release posts, but I have been unable to find any news on this via web searches. But if you look in the right places in MSDN documentation:
There you have it, documented as deprecated and obviously updated some time in the few months to reflect 3.0.
The preview version of the emulator can be found here: Windows Azure Storage Emulator 2.2.1 Preview
The breaking changes from Storage SDK 2.1 and 2.2 to 3.0.2 are available here: 3.0.2 Breaking Changes
The source code for the Storage SDK has moved. Perhaps to one-up the folder restructures that have happened a couple times in the past, they completely moved the storage code from WindowsAzure/azure-sdk-for-net to WindowsAzure/azure-storage-net. The older repository has branches for 1.7, 1.7.1, and 2.0 and tags for 5 flavors of 2.1 (storage sdk? azure sdk?) among others. The new one appears to just be 3.0.2 and, at the time of this writing, seems to be missing a lot of history and all the unit tests.
The MSDN documentation that indicates 1.7 is deprecated can be found here: Storage Client Library (June 2012 and earlier)
Opportunities to Improve
I’m glad Microsoft is releasing more frequently instead of the 2-3+ year gaps it used to take, but I’d like to see them pay more attention to the impact these releases are having on customers.
The move from 1.7 to 2.0 dropped a number of synchronous methods, renamed the namespace, and shipped with the 1.8 Azure SDK which still required the 1.7 version of Storage for the diagnostics library. Right up until 2.0 sprang into the world (literally days prior), developers were still telling us that 1.7.1 was the future and we should be using that for some of the new features (feel free to compare 1.7.1 and 2.0 on github).
I’m also still waiting to see the Storage SDK become friendly to unit testing, between the sealed classes, internal methods, and lack of abstractions, it still requires you to write your own storage abstraction layer on top of their storage abstraction in order to support unit testing.
Subsequent releases haven’t been that bad (after 1.7 to 2.0), but now we have another major version release, this time completely out of step with Azure releases and announced without even announcing the fact that it was a major version upgrade.
Updated versions of the storage emulator trail months behind the release, ensuring slow uptake of new versions or adding additional time and dollar expense by forcing customers to develop directly against real Azure Storage Services accounts.
And the removal of the unit tests doesn’t fill me with a high level of confidence either. I didn’t particularly like the style of the older tests, but at least they were there.
So here we are, at another major release and a silent deprecation of 1.7. I’ve personally wasted a lot of time upgrading from 1.7 to 1.7.1, then throwing that work out when 1.7.1 remained a preview (with all the extra conversation that causes in support cases) and 2.0 didn’t look anything at all like 1.7.1, upgrading to 2.0 and filling in the holes they decided to add, then backing it all out again due to other conflicts and the fact that none of this has any value at all for our customers and…well, you get the picture.
A huge part of the value in releasing more frequently is bringing the pain to the surface and then fixing it. It seems the frequent release half of the equation has happened, now I’m looking forward to the part where they start attacking these pains.