This entry was prompted by this post on the CMCrossroads General CM forum.

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.

Month	Release ID	Purpose
Jan	1.0.1	Maintenance
Feb	1.0.2	Maintenance
Mar	1.0.3	Maintenance
Apr	1.0.4	Maintenance
May	1.0.5	Maintenance
Jun	2.0	Release of change A
Jul	2.0.1	Maintenance
Aug	3.0	Release of changes B and C
Sep	3.0.1	Maintenance
Oct	3.0.2	Maintenance
Nov	3.1	Release of changes D and E
Dec	3.1.1	Maintenance

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.

Month	Release ID	Purpose
Jan	London	Maintenance
Feb	New York	Maintenance
Mar	Paris	Maintenance
Apr	Prague	Maintenance
May	Toronto	Maintenance
Jun	Moscow	Release of change A
Jul	Sydney	Maintenance
Aug	Tokyo	Release of changes B and C
Sep	Budapest	Maintenance
Oct	Kiev	Maintenance
Nov	Munich	Release of changes D and E
Dec	Oslo	Maintenance

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.