My co-workers and I are relatively need to the stream idea with Clearcase UCM. Currently management has created streams for each functional software package, each of which has defined interfaces and lives within a layered architecture. Developers create child streams depending on the package they are working in, and attempt to develop their code independently, however they normally have dependencies on other packages during initial development. This has caused our integration group to create system builds that developers then use to create an adequate environment to develop their software and manually pull in dependencies (i.e. zip files, patches, etc.).
My contention is that this is wrong and not how UCM was intended to be used, but I needed someone more familiar with UCM to confirm my beliefs.
I believe that streams should be created from a functional point of view (while each package does some function, multiple architectural packages contribute to achieving some customer function, call it “ABC”). Then, the component for each architectural component which is perfomring initial development for function “ABC” is added to the stream. All developers for function “ABC” now work in the stream (or in some set of child streams) to complete that function. Once complete you have a baseline for each UCM component, and no “binding” between components exists from UCM’s point of view (someone claimed this could somehow happen within UCM due to Activity Records).
NOTE: I agree that maybe you don’t work this way FOREVER, but during initial development where interfaces commonly change, you haven’t implemented all the interfaces for all functions, and so having multiple components working together in a stream makes the most sense. Later you can transition to a “architectural package-centric” way of working where each package is independent of changes in another.
Thoughts? Sorry for the long post, I felt the detail was necessary.
Yes, that’s pretty much the two UCM normal usages of stream
(the only very bad usage is the one involving one stream per developer, just for isolation purpose, and that would be madness, as specified before)
Those two modes are system approach and component approach, detailed in this answer.
Basically, you want to avoid too much merges or rebase during the initial phase of development and keep one coherent system (with all components writable) at the beginning.
Then, when API is stabilized, you can go one stream per writable component.
Note: that does not prevent you to establish “system integration” streams, when you have a set of well-defined baselines referencing a stable state for all your components (read-only), and where you can deploy and test your system.
Those streams are maintained on one or several separate “integration” UCM projects.