One widely accepted scheme consists of period separated integers. The number of integers varies, as does the interpretation of each integer. Again, I shall be no different here and will present a four integer scheme in which each integer has a specific interpretation.

The general form of the release identity presented in this post is as follows.
major.minor.build.patchThis scheme should be broadly familiar to most release managers, especially those dealing with Microsoft assemblies. Whether my interpretation of each integer comports to expectations remains to be seen.

major and minor

The first to components major.minor are the principal release identity. The major component is incremented when functional change is introduced into the release. The minor component is incremented when non-functional change is introduced into the release.

Generally, a functional change modifies the behaviour of a component but the major component of the identity should also be incremented when there is a change to the interface of the component. This provides a simple means of establishing interface compatibility for system components. It is clear, from the release identity alone, that 1.1 of a library is a drop-in replacement for 1.0. Replacing 1.0 of a library with 1.1 should require no changes to the calling application since, by maintaining the major part of the identity the release manager has declared that there are no functional changes and no interface changes between 1.0 and 1.1.

build

It is an inevitable reality of software development that any release will undergo many rounds of testing, each proceeded by a new build of the software to be released. The build component of the release identity. Some people like to left zero fill the build component so that the release identities are sorted into chronological order when sorted using natural ASCII codes. (That is, rather than starting the build component 1, 2, 3, and so on, they start 0001, 0002, 0003.)

patch

A Patch is a partial release. This could mean that only a part of the build is rebuilt, but the entire system is repackaged for release, or it could mean that only one or two components of the entire system are built and released. Either way, the package identified with a patch is considered an incremental package to be applied in patch number order to the underlying release.

For example, suppose we had released 1.0.123 (build 123 of release 1.0) to testing. After this release a minor issue is discovered in a library package. Rather than re-release the entire package again (as 1.0.124) the release manager decides to release the updated library as a patch. This patch is identified as 1.0.123.1 and consists of only the updated library. Subsequently, another library update is required. Again a patch release is chosen and released as 1.0.123.2. In order to release 1.0.123.2 to any subsequent environment must install 1.0.123, then 1.0.123.1 and finally 1.0.123.2 in order to produce the final, correctly configured, system.

It should be self-evident that this patch numbering scheme is only used in unusual circumstances. It should also be self-evident that the inclusion of a patch number immediately alerts deployment engineers of the need to apply patches and the correct deployment sequence.

Here is a simple way to think about releases and release planning.

Think of a release as a bucket into which change requests can be placed. A release plan is essentially a line of release buckets. Changes can be add to, removed from, or moved between release buckets.

Each bucket is assigned a ‘release date’. This is the date on which that release bucket ceases to exists and the system that results form all its changes is given to the client.

In a very simple development schedule, developers visit the next bucket in line, take out a change, make that change and mark the change as done.

Here are some rules about how the release buckets are used for release planning.

• Each bucket has a certain capacity measured in man days effort. Each change requires a certain number of man days effort to complete. The release manager can add or remove changes so long as the total effort associated with the changes does not exceed the capacity of the release bucket.
• When planning releases it is best to not exceed 80% of the capacity of the release bucket in the early part of the release’s lifecycle. This allows some contingency for late change or some changes already in the bucket overrunning slightly.
• Changes that have not yet been taken by developers can be freely moved between release buckets.
• Changes that have been started by developers can only be moved in co-operation with the developer and software configuration manager. (This is a practical matter of moving the code changes in the version control system.)
• As a release approaches its assigned release date, make it harder to add and remove changes.

I recommend adopting a traffic light approach to locking down a release; green (changes can be added and removed freely, providing 80% of the bucket’s capacity is not exceeded), amber (changes can be added or removed only with senior project approval, 80% capacity can be exceeded if approved), red (no further changes other than for integrating emergency patches from live).

The precise meaning of terms such as ‘senior project approval’ will be different for different projects. The point is, it should be more difficult to make changes to the content of the release bucket once it is in the amber condition.

As for when you set a release to amber or red, that depends on your own schedule, the size of your release, and the resources available.

I see nothing fundamentally wrong with Victor’s definition of release management.

Software Release Management Process is the process through which proper versioned software is made available (Released) to the Client

It is unclear from this definition precisely what scope Victor anticipates release management will have, but I will assume the scope to include the planning, scheduling and control of software builds (and consequent baselines) through the various development and test environments, and ultimately preparation for delivery to the client. I shall exclude the release into an operational environment because this is a quite different type of release management to that being addressed in the thread.

I see no conflict between Victor’s definition of release management and the possibility of multiple releases with potentially complex relationships.

I disagree absolutely with Victor’s contention that “If we go forward as above, we are breaking the fundamental principals of configuration management.” This is simply wrong. There is absolutely nothing in the “fundamental principals of configuration management” that demands release identities proceed in an contiguous fashion. At best, one might make the case that in the best of all possible world, it is desirable that release identities progress in a contiguous sequential fashion. Hopefully this article will make my reasoning clear.

Victor is correct that there could, at any one time in a product’s lifecycle, be multiple baselines and some will never be released to the client. In fact, I would go so far as to say that is inevitable. Large scale, modern development often involves multiple parallel development streams which inevitably have overlapping release schedules, and these can become quit complex.

The real world is always much more messy than theory might like to present it. SCM and particularly, in this context, release management’s role in this is to ensure control, not impose linearity.

In order to clarify this discussion I want to distinguish a Release from a Baseline. These two terms are too often used interchangeably and this makes discussions difficult.

For the purpose of this article, a Release is a planned set of changes, and a Baseline is a collection of artefact versions. To make this distinction clear, I offer the following concrete example.

Let us limit our conversation to a single application (ProductX). ProductX has been released to clients as version 1.0.

The business plan five changes to ProductX over the next year. These changes are identified as changes A, B, C, D and E.

The organisation uses long term planning and a combination of development methodologies, which are applied according to their appropriateness to the task. In this example the changes are such that Agile methods are not considered appropriate, besides the organisation has insufficient qualifies people to lead Agile development for all the changes. (I include this detail to anticipate people insisting that using an Agile approach would solve the problem. This article is addressing a specific point of release management. If you would like to debate Agile methods and their appropriateness to projects, please read Balancing Agility and Discipline by Barry Boehm and Richard Turner first.)

The release schedule being planned runs from January through to December.

The business has also promised the clients monthly maintenance releases.

Without any consideration to the proposed changes A through E, release management schedule twelve monthly maintenance releases. In order that maintenance work can be scheduled, these releases are initially identified as releases 1.0.1 through 1.0.12.

After assessing changes A through E proposed by the business it is agreed that change A will deliver some major new functionality, so the release will be designated 2.0. Change A will take six months to develop, so release 2.0 is scheduled for June.

Changes B and C are to be delivered together and will add further functionality to the system This release is identified and 3.0 and is scheduled to August. The actual project start date will be in March, so work on 3.0 will overlap with 2.0. This is not seen as a problem and integration points are planned to ensure work from 2.0 is propogated into 3.0 on an agreed schedule.

Changes D and E are similarly planned. The release is identified as 3.1 because these are non-functional changes. 3.1 is planned for release in November and work is expected to start in April because there is a significant amount of back-end modification required.

Once these major milestones are planned release management re-designates the 1.0.x releases with new identities so that they conform to the new schedule. This causes no difficulties at this point because only release management and change management are concerned with scheduling work into these releases.

The stage is set. ProductX’s release schedule looks like this.

So far, so good. Whether the release identities are good or bad is irrelevant so far as release management (we will see how they cause difficulties later). We could just as easily designated them with names like the following and precisely nothing would have changed so far as the release management process is concerned.

Release identities are used to schedule changes.

Development starts

Work begins in January on release 2.0 and 1.0.1. Baselines are produced to identify builds of ProductX that are submitted to testing; 1.0.1.01, 1.0.1.02, and 2.0.0.01 and 2.0.0.02

None of these baselines is released yet. In the 1.0.1 release schedule two builds have been produced. Perhaps they were integration and system tested, but not user tested because there were more maintenance changes to be made.

The 2.0.0.x baselines were integration tested. These tested used the same test environments as the 1.0.1.x baselines but no confusion resulted as SCM and release management co-ordinated with test management to ensure the environment was correctly configured with a known baseline at the start of each test cycle.

Finally a baseline 1.0.1.03 is created and completes the test cycle, being release to clients. This baseline 1.0.1.03 is the first to be released. Baselines 1.0.1.01 and 1.0.1.02 are discarded, never to be released. The organisation has been juggling releases 1.0.1.01, 1.0.1.02, 1.0.1.03, 2.0.0.01, 2.0.0.02 in and out of test environments with absolute clarity because both SCM and release management have managed the baselines, environments, and stakeholders professionally.

A baseline 2.0.0.03 is produced to integration test the inclusion of changes from 1.0.1.03. Everything is fine. This integration ensures that when 2.0.0.x is release it will not regress changes made in release 1.0.1.03.

Precisely when these integration baselines are created is a matter for another article. (Like so much else in SCM judging when to create release streams, how much to integrate, and when, is often a matter of experience.)

Release 3.0 starts

Work proceeds like this until March when work starts on the planned release 3.0. Baselines for release 3.0 proceed 3.0.0.01, 3.0.0.02. These are necessarily produced in parallel with maintenance releases and, of course, releases for 2.0.

Release 3.1 starts

In April, things become even more complex. Work for 3.1 is started. So now we have baselines for maintenance work (by now release 1.0.4, so builds 1.0.4.01, 1.0.4.02 and so on), release 2.0 is nearing release (2.0.0.023, 2.0.0.24, …), release 3.0 work is well underway (3.0.0.05, 3.0.0.06, …) and now release 3.1 (3.1.0.01, 3.1.0.02, …) joins the melee.

One might argue that this work should all be nicely ordered and sequential, but practical, commercial reality has a tendency to make this sort of complex release scheduling increasingly common.

While release management may advise the business on the wisdom of release schedule changes, it remains the businesses decision. If release management dictate the release schedule to the business then this is a case of the tail wagging the dog. If you feel that release management should have the authority to override business decisions I suggest you look at another line of work – you’re wrong.

During all this, changes need to be properly sequence from one release to the next to ensure changes are not regressed by subsequent releases.

A spanner in the works

Then, in mid-April the business get a request from clients to support a new feature. Clients want ProductX to support a hot new Internet craze. The business identify this as a potentially major source of revenue.

A hasty change is raised and assessed. The amount of work required to add the new feature is relatively small. The business are keen for the new feature to be available as soon as possible.

After looking at resources and schedules it is agreed that the 2.0 release in June is too close to consider adding the functionality to that release. There is too much to release as part of the maintenance cycle and release 3.0 in August is too far away. Ideally a mid-June release, just after 2.0 is the best from a Business point of view and is achievable with current resources.

What should release management do?

If the slavishly follow the release numbering scheme, which demands that the major identity number is raised when new functionality is added, they should move the current 3.0 to 4.0, 3.1 to 4.1 and create a new 3.0. This, to me, seems patently absurd (and a good argument against assigning strict meaning to release numbers in the first place). This approach most certainly would cause confusion. Baselines produced for 3.0 prior to the change would be confused with those after, it would be a monumental mess.

A more practical solution is to create a 2.1 release. This breaks the strict convention of release numbers established by the organisation, but preserve some semblance of order.

Notice that if releases were not identified by numbers like this the problem is moot. Suppose releases were identified by city, as shown above. Adding the new release is trivial, just add a new release ‘Bangkok’ between Moscow and Sydney.

The point being, that the problem is absolutely nothing to do with the release management process and everything to do with the choice of how releases are identified.

A couple of closing thoughts

Firstly, if you made it this far, well done.

This is not a trivial problem and there are many, many ways to address it.

One could, for example, argue that creating a more incremental release strategy (a la Agile) would solve the problem. This is a naive observation. Such release schedules are not always the solution, indeed they are often not practical or even not possible on larger projects. There is no one-size-fits-all solution to release scheduling, but investigating alternatives is always helpful.

One might also make a case for rigidity. Release management should push back on the business, pointing our the cost of changing the schedule and the minimal benefit, and the business would be foolish to not listen. In the example above a strong case could be made for dropping the surprise functionality into the next maintenance release, or even integrating it into 3.0 in August. As with so many things, it depends. How much impact does it have on 3.0 functionality? Is it a risky change? Should it be isolated from other releases until implemented, then integrated into an appropriate release? There are many, many possibilities.

The simplest solution is to completely de-couple the three types of identity; release planning, baselines, and releases to clients.

These discussions must always be tempered by practical reality. Release management, like any other management discipline must be able to satisfice (to find a way forward that provides the best available outcome for all stakeholders, including SCM and release management). A satisficing solution is seldom the ‘best’ solution for all stakeholders.