Versioning

[Lance Waterman <la...@gmail.com>]

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.B are 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

Re: Versioning

[Matthieu Riou <ma...@gmail.com>]

Yep, I'm happy with that.

On 8/9/06, Lance Waterman <la...@gmail.com> 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 <arkin@intalio.com > wrote:
> >
> > On 8/9/06, Lance Waterman <la...@gmail.com> 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 < arkin@intalio.com> 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 <la...@gmail.com> 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
> >
> >
>
>

Re: Versioning

[Lance Waterman <la...@gmail.com>]

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 <arkin@intalio.com > wrote:
>
> On 8/9/06, Lance Waterman <la...@gmail.com> 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 < arkin@intalio.com> 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 <la...@gmail.com> 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
>
>

Re: Versioning

[Assaf Arkin <ar...@intalio.com>]

On 8/9/06, Lance Waterman <la...@gmail.com> 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 <ar...@intalio.com> 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 <la...@gmail.com> 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

Re: Versioning

[Alex Boisvert <bo...@intalio.com>]

Lance Waterman wrote:
> Assaf,
>
> I agree with you and this is how I would set up a deployment policy ( if
> someone were to ask me to ) however, I think Alex's point is that process
> definition policy should be enabled by ODE and not necessarily 
> enforced by
> ODE ( see gun pointed at own foot ).
Just to be clear, I am not against having the engine enforce lifecycle 
management policies, as long as those are pluggable or can be exercised 
by external tooling.  At the core, I'd prefer an engine that supports 
different policies.

alex

Re: Versioning

[Assaf Arkin <ar...@intalio.com>]

On 8/10/06, Lance Waterman <la...@gmail.com> wrote:
>
> Assaf,
>
> I agree with you and this is how I would set up a deployment policy ( if
> someone were to ask me to ) however, I think Alex's point is that process
> definition policy should be enabled by ODE and not necessarily enforced by
> ODE ( see gun pointed at own foot ). The only policies that I think ODE
> must
> enforce are those listed by Maciej:


I agree with this principle, when it comes to the basics of deploying
processes.

But if we want to have the convenience of history of versions of the same
thing, then we're asking for restrictions. We're essentially asking the
process engine to keep track of one version that replaces another out of
convenience, so it's reasonable that the deployment policy would replace one
version with another.

If on the other hand we want to create a new naming mechanism out of tuples
of namespace, name and number, I don't see justification for that. QNames
are an infinite naming space already, flexible enough and work the same way
across the entire stack.

Let's just keep to what works.

Assaf


> 2. An operation used in version n, must have the same signature in
> > version n+1
> > 3. A data type used in version n, must have the same definition in
> > version n+1.
>
>
> Thoughts?
>
> Lance
>
> On 8/9/06, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > I don't see it that way.
> >
> > If I wanted to deploy Foo side by side with Bar, I would create a
> process
> > Foo and a process Bar, with distinct names that may differ only in
> version
> > number.
> >
> > If I'm deploying Foo for the third time (v3), it's because I'm replacing
> > Foo(v2), itself replacing Foo(v1). And the element of least surprise is
> > that
> > new version is activated, while old version is retired. Consistently.
> >
> > Otherwise, I accidentally change the endpoints in Foo(v3), and all my
> test
> >
> > cases keep working even though they should be failing, because Foo(v3)
> is
> > wrong, but Foo(v2) is still active.
> >
> > Assaf
> >
> > On 8/9/06, Alex Boisvert <boisvert@intalio.com > 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
> > >
> > >
> >
> >
> > --
> > CTO, Intalio
> > http://www.intalio.com
> >
> >
>
>


-- 
CTO, Intalio
http://www.intalio.com

Re: Versioning

[Lance Waterman <la...@gmail.com>]

Assaf,

I agree with you and this is how I would set up a deployment policy ( if
someone were to ask me to ) however, I think Alex's point is that process
definition policy should be enabled by ODE and not necessarily enforced by
ODE ( see gun pointed at own foot ). The only policies that I think ODE must
enforce are those listed by Maciej:

> 2. An operation used in version n, must have the same signature in
> version n+1
> 3. A data type used in version n, must have the same definition in
> version n+1.


Thoughts?

Lance

On 8/9/06, Assaf Arkin <ar...@intalio.com> wrote:
>
> I don't see it that way.
>
> If I wanted to deploy Foo side by side with Bar, I would create a process
> Foo and a process Bar, with distinct names that may differ only in version
> number.
>
> If I'm deploying Foo for the third time (v3), it's because I'm replacing
> Foo(v2), itself replacing Foo(v1). And the element of least surprise is
> that
> new version is activated, while old version is retired. Consistently.
>
> Otherwise, I accidentally change the endpoints in Foo(v3), and all my test
>
> cases keep working even though they should be failing, because Foo(v3) is
> wrong, but Foo(v2) is still active.
>
> Assaf
>
> On 8/9/06, Alex Boisvert <boisvert@intalio.com > 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
> >
> >
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>
>

Re: Versioning

[Assaf Arkin <ar...@intalio.com>]

I don't see it that way.

If I wanted to deploy Foo side by side with Bar, I would create a process
Foo and a process Bar, with distinct names that may differ only in version
number.

If I'm deploying Foo for the third time (v3), it's because I'm replacing
Foo(v2), itself replacing Foo(v1). And the element of least surprise is that
new version is activated, while old version is retired. Consistently.

Otherwise, I accidentally change the endpoints in Foo(v3), and all my test
cases keep working even though they should be failing, because Foo(v3) is
wrong, but Foo(v2) is still active.

Assaf

On 8/9/06, Alex Boisvert <bo...@intalio.com> 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
>
>


-- 
CTO, Intalio
http://www.intalio.com

Re: Versioning

[Matthieu Riou <ma...@gmail.com>]

I can't see why you would want to have 2 versions of the same process both
active on different endpoints. Why not just having another process? Are you
thinking of particular use cases where this would make sense?

On 8/9/06, Alex Boisvert <bo...@intalio.com> 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
>
>

Re: Versioning

[Lance Waterman <la...@gmail.com>]

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 <bo...@intalio.com> 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
>
>

Re: Versioning

[Alex Boisvert <bo...@intalio.com>]

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

Re: Versioning

[Lance Waterman <la...@gmail.com>]

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

On 8/9/06, Assaf Arkin <ar...@intalio.com> 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 <la...@gmail.com> 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.B are
> > 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
>
>

Re: Versioning

[Bruce Snyder <br...@gmail.com>]

On 8/9/06, Assaf Arkin <ar...@intalio.com> wrote:
> Bruce,
>
> That's what "retired" means. A process is retired so it can continue
> executing existing instances, but not instantiate new ones. Undeploying is a
> separate step that also removes all the instances.

OK, thanks for the clarification, Assaf. I guess I should have asked
for a clarification of terms ;-). Now I see the light.

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/

Re: Versioning

[Assaf Arkin <ar...@intalio.com>]

Bruce,

That's what "retired" means. A process is retired so it can continue
executing existing instances, but not instantiate new ones. Undeploying is a
separate step that also removes all the instances.

Assaf

On 8/9/06, Bruce Snyder <br...@gmail.com> wrote:
>
> On 8/9/06, Assaf Arkin <ar...@intalio.com> 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.
>
> What about a rolling deployment scenario? This might take place in a
> production situation where P.v1 needs to remain active to service
> client requests that are already open and running but P.v2 needs to be
> used to service any new requests? I'm not sure that covering this case
> using unique names is exactly the solution.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo - http://geronimo.apache.org/
> Apache ActiveMQ - http://incubator.apache.org/activemq/
> Apache ServiceMix - http://incubator.apache.org/servicemix/
> Castor - http://castor.org/
>



-- 
CTO, Intalio
http://www.intalio.com

Re: Versioning

[Bruce Snyder <br...@gmail.com>]

On 8/9/06, Assaf Arkin <ar...@intalio.com> 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.

What about a rolling deployment scenario? This might take place in a
production situation where P.v1 needs to remain active to service
client requests that are already open and running but P.v2 needs to be
used to service any new requests? I'm not sure that covering this case
using unique names is exactly the solution.

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/

Re: Versioning

[Assaf Arkin <ar...@intalio.com>]

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 <la...@gmail.com> 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.B are
> 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