Okay - sounds like we are on the same page. Since "active" is a mutually exclusive state value I'm not sure I see the need for the other value "current".
Is everyone else in consensus with this ( Alex, Maciej, Matthieu )? Lance On 8/9/06, Assaf Arkin <[EMAIL PROTECTED] > wrote:
On 8/9/06, Lance Waterman <[EMAIL PROTECTED]> wrote: > > So if I understand correctly you are saying there should only be one > "active" process definition at any given point in time? From the example; > when P.v2 is deployed it is implied that P.v1.A becomes inactive and any > messages targeted at P.v1.A would fail to route within the engine. Yes. If the above statement holds true with everyone then I think we are in > agreement and we need to decide on a naming convention for these process > definition states. > > I have been using the convention "current" and I think Maciej suggested > "legacy" for the converse ( I would suggest "deprecated" as an alternative > ). > > I think Alex prefers the terms "active" and "retired"? > > Thoughts? All three? Let's say I deploy process P, and then decide I no longer want to offer that process. But I don't want to undeploy it until all the current instances have completed. So I want it to enter that state where instances are still running, definition still available, but you can't start new instances. So now I have a distinction between active (can instantiate) and retired (can't instantiate, still deployed). I think active/retired are good names to communicate what's going on, separately from deployed/undeployed. When it comes to versioning, if I deploy P.v2 which takes over P.v1, and then deploy P.v3 which takes over P.v2, I end up with running instances of all three versions, but you can only instantiate P.v3. So given the exact same way of looking at process definitions, I still have that active/retired distinction. But I also know all three are related, and P.v3 substitutes the other two. So whether we like it or not, there's also the notion of "current", which happens to be the only active definition of a given process name. I think we should keep current as well. Assaf Lance > > On 8/9/06, Assaf Arkin < [EMAIL PROTECTED]> wrote: > > > > My expectation as a developer, is that whenever I deploy a new version > of > > the same process, the old version is retired so the new version is > > activated. And if I intend to deploy two processes side by side, I > should > > pick different names to distinguish them. > > > > Anything else would surprise me. > > > > Assaf > > > > On 8/9/06, Lance Waterman <[EMAIL PROTECTED]> wrote: > > > > > > I would like to start a new thread on this since I don't believe this > > > really > > > has anything to do with issue 10 and I was beginning to get lost in > the > > > thread context. > > > > > > I have put more thought into Alex's comments and would like to see if > > more > > > use cases could help clear things up. Sticking with Alex's uses cases > I > > > believe he has defined process P with v1 and v2 where v1 has > > instantiating > > > operation A and v2 has instantiating operation B. I would like to add > v3 > > > > > which has instantiating operation A ( identical to v1 ). > > > > > > P.v1 is deployed > > > > > > P.v2 is deployed. My impression from Alex is that P.v1.A and P.v2.Bare > > > both > > > "active" ( both are available to the client and both will instantiate > a > > > new > > > process ). I must use some management tooling to explicitly "retire" > > P.v1. > > > Is this correct? > > > > > > P.v3 is deployed. This is where I need some help in understanding. Is > > > P.v1.Astill active or because the signature is the same, > > > P.v1.A is implicitly retired? > > > > > > Lance > > > > > > > > > > > > -- > > CTO, Intalio > > http://www.intalio.com > > > > > > -- CTO, Intalio http://www.intalio.com
