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: Issue 10 / Versioning
Date Thu, 10 Aug 2006 15:38:26 GMT
Alex,

Could you please walk through a couple of deployment/management scenarios
and talk about how/when process definition state changes ( "active",
"retired" ) explicitly vs. implicitly. I'm hoping this exercise will help me
understand this statement:

>>The deployment rules for two such processes
>>would be the same as if they did not share common name+namespace.

Given collisions ( see Maciej's restrictions 2 and 3 )  within the same
name+namespace ( at runtime ) I don't see how these can be the same at
deployment time.

Thanks,

Lance

On 8/10/06, Alex Boisvert <boisvert@intalio.com> wrote:
>
> Maciej Szefler wrote:
> > I propose that we do not put too many restrictions on what a new version
> > of a process looks like. It only needs to enforce the following rules:
> > 1. A service exposed in version n, must also be exposed in version n+1
> > 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.
> >
> Personally, I still find this too restrictive.  My proposal would be to
> consider the version attribute as part of the process identifier --
> effectively making two processes with the same name+namespace but with
> different version identifiers completely unrelated from an
> implementation standpoint.  The deployment rules for two such processes
> would be the same as if they did not share common name+namespace.
>
> alex
>
>
>
>

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