ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Versioning
Date Thu, 10 Aug 2006 16:44:39 GMT
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 <arkin@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
>
>

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