ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matthieu.r...@gmail.com>
Subject Re: Versioning
Date Wed, 09 Aug 2006 19:06:53 GMT
Yep, I'm happy with that.

On 8/9/06, Lance Waterman <lance.waterman@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 <lance.waterman@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 <lance.waterman@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
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message