In general it seems like you are advocating the decoupling of process deployment from its state ( i.e. active/retired ) in the cases you have outlined here. Are you proposing that management tooling is required to "retire" the P(v1) process definitions sometime after P(v2) has been deployed?
In the case of the following deployment: P(v1) with operation "foo" on endpoint "bar" P(v2) with operation "foo" on endpoint "bar" Are you saying that P(v1) would be implicitly "retired"? Lance On 8/9/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Sorry Lance, I still disagree. I think the engine should allow simultaneous deployment and activation of: P(v1) with operation "foo" on endpoint "bar" P(v2) with operation "foo" on endpoint "baz". or P(v1) with operation "foo" on endpoint "bar" P(v2) with operation "foz" on endpoint "bar". These are just two examples but they illustrate what I consider a valid use-cases. alex Lance Waterman 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. > > 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? > > Lance
