Change Management: Project Release Numbering

In a previous post I said I'd post something about my numbering scheme for release candidates. If you recall from the previous post, a release candidate is the set of code that will be moved from development to a higher environment. They are complete enough that by packaging and releasing them we are saying 'this set of items can move into production'. This is the key to change management in these environments. If you are working in an Agile environment you may have a release every iteration, if not you may be releasing things more infrequently than that. This system is meant to be simple and fit with the change management process defined in the earlier post.

Any version numbering scheme should be developed to fit your change management process. An initial version of a project will be Version 1. Changes after that are tracked using our numbering system below. A change will increment either the major or minor revision number (very loosely and very purposefully defined as 'depending on the impact of that change') as follows;

• A Version Number is incremented when a project is wholly changed or rebuilt.
• A major change to a version will increment the Major Revision Number.
• A minor change to a version will increment the Minor Revision Number.
• A Patch can be applied if a change to an existing version is required (rather than a rebuild and increment). Additional patches increment the Patch Number.

Any specific release can be recreated by starting with that version's code sequentially applying all patches.

*Note, In my environment I don't need release things to users before they are production ready. If you you wish to denote that something being released to customers is in a pre-production state, I would call that a version 0, use the numbering scheme above for changes to that product and attach a greek alphabet prefix (Alpha, Beta, etc) to each release version in this pre production state.

See Also:

• Agile BI - Ralph Hughes

Do you do mentoring in your BI department?

I came across an interesting article on types of mentorship in this twitter post:

Keeping Great People with Three Kinds of Mentors - Anthony Tjan - Harvard Business Review: http://t.co/PbQv3bg via @AddThisless than a minute ago via Tweet Button Favorite Retweet ReplyIan Di Tullio
ianditullio

Do you do mentoring in BI? I am very much in favor of mentoring. The secondary point of this article is almost more interesting to me,

One of the most critical elements in retaining great people is effective mentoring. 

The community of BI developers is small, and the community of great BI developers is even smaller. If you come across one, hire them or work for them! Mentoring can be a great retention method for talented employees. Simply put, good people want to work for more experienced good people.

See Also:

•  Keeping Great People with Three Kinds of Mentors

Back from Tufte

I spent the day yesterday attending Dr. Edward Tufte's excellent course/seminar/inspirational speech "Presenting Data and Information". Attend this course if you get a chance.

Making a presentation is a moral act as well as an ethical and intellectual act.

You'd do well to remember that as a BI developer. EVERYTHING you develop is a presentation. A report, a database table, a fancy dashboard, are all presentations and all tell a story. They become an attempt at concert between what you built (the system), and the user. Now that we've elevated reporting to a moral level, Dr. Tufte urges us to address the content ('do whatever it takes to show the content') with the moral weight of the previous statement. Therefore,

The presentation stands and falls on the quality, relevance, and integrity of the content.

Dr. Tufte is an engaging speaker and I came away with pages of quotes and notes to share. But it seems the blogosphere has done it already (also it seems this course hasn't changed much in a year), check out this post for most of the gems I wrote down during this course. So I can quote ET quoting TS Elliott, "Talent imitates, but genius steals".

A day with edward Tufte

Tufte Design Principals