Yep, I'm happy with that. On 8/9/06, Lance Waterman <[EMAIL PROTECTED]> wrote:
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 > >
