CM Generations and a Vision for the Future

• generic Change-based IDE API.

In this generation we start to see new capabilities, perhaps a few that we question or simply don't understand. Yet side by side we see capabilities that have been around in some tools for ages (e.g. IBM ClearCase's Integration of Views with the OS File System; Neuma's CM+ Change-based promotion). Still many questions and concerns: Can I really eliminate labelling and why do I want to? How can we reduce branching and merging without compromising our CM process? It can't be done! - can it?

The key to developing successful 3G tool capabilities is first to recognize why different CM patterns and strategies are used, and then to automate these. 2G tools provided a lot of new capabilities, but these were not properly guided. Triggers, labels, branches, permissions, views - all fine, but all requiring significant guidance. To develop a 3G tool, a new mindset is required. Although the capability is important, the use of the capabilities is more so. In a 2G world, every shop decides how it's going to do branching, labelling, views, etc. In a 3G world, the tool determines how and guides you based on your required use cases, and then allows you to customize.

First class objects are crucial for items such as changes, baselines, builds, and branches. It's no longer sufficient to identify a change as all file revisions which referenced a particular task. Change workflow is not the same as task workflow. It's insufficient to identify a build by all the revisions with a particular label. A build needs its own workflow, and needs to be promoted through integration, testing and perhaps the release process. Branches are not just another way of numbering a revision, they have a number of properties peculiar to them which do not need to be associated with revisions.

Use of an appropriate set of first class objects eliminates so many complexities that the configuration management task can be automated and replaced with a change management task: What changes are we promoting today? Which changes do I need to include this feature in my build? Which changes fix the "gating" problems for the next beta release? These decisions replace CM tasks such as: How do I label these files to promote them and do I have to do merges? Do I have to label all of the files for this build or can I use a set of labels to specify it, and add a label for the new changes?

Tedious planning and setup tasks should also be left to the CM tool. What is our branching strategy and how should it change as we begin work on the next major release? How do I define my configuration view to work on a particular build or development stream? Yes, these all appear to be valid questions and concerns, but in a 3G CM tool, the concern is left for the CM tool, while developers and CM managers focus more on change management. The key shift is to guided automation and this will grow over the next two or three generations of CM tools.

Change the first-class objects and the developer’s life is made easier too. A developer can select a product and development stream, or perhaps a specific build identifier, rather than defining or using configuration view. Once this context is established it can be modified by including changes (i.e. specific change packages), if necessary, or by specifying a specific test/promotion level the user wishes to work to - the latest build level instead of the most recently submitted files, for example. The developer doesn't