Defect/Enhancements for multiple releases

No one's come across this situation before?

Hello All, apologies if this topic has been discussed.

How do you all use RTC for a WI, (defect/enhancement) when it has to be fixed in multiple active releases (or parallel development). So, for example, if something needs to be fixed in

RTC 3.0.1.x
RTC 3.0-ifix00x
RTC 2.0.x

Do you create more than one WI for each release? What about the code?

thanks...

In the RTC development project itself, we commonly create a work item
(defect, enhancement request) and fix it in a given code stream. If
this change needs to be applied to another stream, we would just deliver
it to that other stream. If conflicts/gaps need to be resolved (i.e.
more code changes need to be made) before it can be delivered, then we
would create a task work item to do that work, and mark that task work
item as "related to" the original work item.

But there are various reasonable alternatives. One is to strictly
separate the "issue" (defect, enhancement request) from the task to
perform the required work. This is more symmetric, since then every
stream has its own "task" for the "issue". But it leads to a lot of
"extra" tasks, which is why we don't currently use that approach for
self-hosting.

Cheers,
Geoff

On 3/1/2011 1:38 PM, itengtools wrote:

Hello All, apologies if this topic has been discussed.

How do you all use RTC for a WI, (defect/enhancement) when it has to
be fixed in multiple active releases (or parallel development). So,
for example, if something needs to be fixed in

RTC 3.0.1.x
RTC 3.0-ifix00x
RTC 2.0.x

Do you create more than one WI for each release? What about the code?

thanks...

Hello All, apologies if this topic has been discussed.

How do you all use RTC for a WI, (defect/enhancement) when it has to be fixed in multiple active releases (or parallel development). So, for example, if something needs to be fixed in

RTC 3.0.1.x
RTC 3.0-ifix00x
RTC 2.0.x

Do you create more than one WI for each release? What about the code?

thanks...

The SCM team typically creates a "backport fix" task when something has been fixed in latest and should be fixed in an older stream. The task is linked to the original work item so that any discussion on the approach to fix the issue can be followed. The task helps us track when the fix has been applied and link to change sets required to complete the fix (changes in latest often require more tweaking to get it to work in an older release).

If your code can easily be delivered to all streams without extra changes, you may want to create approvals in the work item. This can track that the change has been delivered to a particular stream and is ready to be test (or has been tested).

I think either method can work as well as any other methods that can be suggested. It all depends on what works best for your team. I personally like separate tasks for porting a fix to an older release. It tracks that it has been done and an approval can be assigned to test the fix. It can be more overwhelming with the number of work items but applying a fix to an older release generally requires extra work that can be its own work item.