Beginning of the development. Test (on GPL.UseCase3.Conversation.Initiator) – both are set to test without the confirmation dialog (if there are no conflicts then we don’t disturb the user). It’s no matter if you do it on Initiator or Participant. I suggest Initiator because then you can directly start the test of both processes. If you do it on participant then you can test only isolated process.
Situation in DBRelease (on GPL.UseCase3.Conversation.Participant) – we should again release the Initiator directly, but we'll try it on the Participant to demonstrate that it really doesn’t matter. We are informed about dependencies and have to confirm release. Activate – both processes are activated together even when you activate just on one of them, because of message flow dependencies between them Now we show only some situation during further development of processes Activate – GPL.UseCase3.Conversation.Initiator version 2 Note that GPL.UseCase3.Conversation.Initiator v2 deployment 0 is “Retired”. Change process Participant – Test – Release Situation among released versions when we do changes step by step. It leads to message flows between versions. Activate – the same situation, old versions are retired Change both processes Initiator and Participant before Release There is no mixture between versions because we have a new version for both processes. Activate – the same situation like after release | |||||