WRT making streams as flow targets of other streams, just ignore that.
It has no semantics ... think of it as just a comment on how you intend
those streams to be used.

WRT the stream structure following the release, I recommend keeping the
3.0 development stream as the 3.0 maintenance stream. To reflect his,
just call it the "3.0 stream". When you are ready to begin work on the
next release (say, 3.1, create a "3.1 stream"). The reason I recommend
this approach is that there are some times when you want to start work
on 3.1 development before 3.0 development is complete.

As for how changes are flowed from the 3.0 stream to the 3.1 stream,
that is done by a workspace. In particular, accept all the changes from
the 3.0 stream, then accept all the changes to the 3.1 stream, and
deliver the results to the 3.1 stream.

Cheers,
Geoff

On 10/22/2010 5:22 PM, jimblye wrote:

Are there any best practices for doing maintenance with RTC?

In other words, after I've finished my first cycle with RTC and have
shipped my product, what do I do next? I mean besides go to Disney
World ;-)

Do I create a new stream for the next release? If so, then the old
stream becomes my maintenance stream. Do I make the new stream a
flow target of the maintenance stream? If so, then how are changes
accepted from the maintenance stream into the new stream? Who does
the accepting?

I am hoping someone out there has been using RTC for more than one
product cycle and can share their experience. Trying not to
reinvent the wheel.

I see the ability to create streams as flow targets of other streams,
but don't see how this works, can't find any documentation on the
subject, and don't know anyone else using this. All I've found so
far are other people who are just as confused as I am. Please point
me in the right direction.

Thanks.

The RTC team itself uses separate streams and builds for maintenance and these are associated with separate maintenance areas that different permissions. For maintenance for example, stability is the highest priority and we typically only want specific defect fixes being made and so deliveries may require more approvals than we would have in a main development stream.

We always have the concept the main stream of development and when we finish a release we continue on the with the next main one in which we are doing new feature work. Any maintenance work on the release is done in the separate stream which is created initially from the snapshot of the release.

Even for a single stream of development such as say 3.0, there is still the concept of maintenance on specific milestones. As an example, if you look at the RTC download pages, you will that occasionally we had an "a" release such as 3.0 M4a, M4b, M5a, M6a, M7a. In fact we've had more of those in this cycle of development than any other, as it has been a crazy development cycle. Each time we produced those "milestone updates" we did them with separate streams and builds because the majority of the team was working on the next milestone and only a few people were involved in delivering critical fixes to the milestone update. In addition to this, we also have our 2.x and 1.x maintenance work in separate streams.