Couchbase .NET SDK 1.3.1 Released!

by jmorris 8. January 2014 14:36

Heads up that the Couchbase .NET SDK version 1.3.1 was released officially yesterday! This release is mostly a maintenance follow up to the 1.3.0 release which added significant improvements (a rewrite of) the connection pooling portion of the client.

A list of issues and tasks that were resolved:

  • NCBC-289: Does not return errors object on exception
  • NCBC-344: NotImplementedException when storing against MemcachedClient in v1.3 client
  • NCBC-345: Update Readme.mdown to reflect changes in the Couchbase .NET SDK versioning policy
  • NCBC-353: Add node IP to error messages so that users can isolate issues easier
  • NCBC-352: Flag all Increment/Decrement methods with CAS params as 'Obsolete'
  • NCBC-337: Fix for 'View vquery was mapped to a dead node, failing.' errors
  • NCBC-341: AOOR when deserializing bootstrap config with empty 'pools' element
  • NCBC-327: Update Nuspec files to current VS Solution Configuration
  • NCBC-334: Add a post-merge git hook for updating the assembly version

The release is available on Nuget: https://www.nuget.org/packages/CouchbaseNetClient/1.3.1 or from S3: https://packages.couchbase.com.s3.amazonaws.com/clients/net/1.3/Couchbase-Net-Client-1.3.0.zip

Tags:

couchbase

Recipe for Disaster - Naming a Release after a Feature

by jmorris 8. October 2009 22:22

Note: This post was motivated by a 3 hour discussion with a release manager regarding why the name of the release was the same as a feature that we had pushed to a future release – “If feature x has moved to release y, why are we still releasing a build called feature x."

Why? Simple, it holds you and/or the team accountable for releasing the feature in that release on the planned date. This doesn't sound so bad one would think. After all, the feature was conceived hopefully from some end user or business need, feasibility was assessed, and the sprint was planned with dates engraved in stone. The reality is that while LOE can be estimated, there are additional factors at hand that wreck havoc on what will be completed by the cut-off date.

Typically, common cause variance can be mitigated and the estimate included in the original LOE, however the same cannot be said for special case variance.  For example, you can pretty much assume that a certain amount of effort will be attributed to research and discovery, before the developer even starts working on the task or feature. While in the exceptional case a developer may have sufficient domain experience to simply start coding a whip out the feature, the rule is that the developer will have to spend time familiarizing them with the environment, before jumping in. This is expected to cause a certain amount of containable variance with respect to a project or sprint. However, how do you reasonable plan the case where another developer on the team contacts some grave illness, such as swine flu and is not available and reduces the number of resources available?

In cases such as this, we simple do not plan for these special cases, because it is virtually impossible. If you did try to plan for them, you would never finish planning because there are an infinite number of things that can happen. It costs too much to plan for these types of things!

Back to my original point, when you name a release after a feature you commit yourselves to completing that feature and releasing it on the planned date, however you omit the possibility of special case variance affecting the outcome. In which case you still want to release something so maybe you release another, less resource feature; but the release is named after the feature that was omitted…this is awkward (especially for the build engineer).

You will communicate your intentions better (i.e. the goal is a release, not necessarily the release of a specific feature) if you name the release after some arbitrary name not tied in directly to a feature.

Tags: , ,

Jeff Morris

Tag cloud

Month List

Page List