ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <boisv...@intalio.com>
Subject Re: Issue 10 / Versioning
Date Thu, 10 Aug 2006 16:02:18 GMT
Alex Boisvert 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.

As further clarification, I think it should be a responsibility of the 
tooling around the engine to define/enforce a given deployment and 
activation policy.  For instance, the tooling could automatically 
undeploy or retire previous versions of a process when deploying a new 
one.  It could even automatically wipe out previous instances if I'm 
working in development mode (versus production).

So I would prefer an approach where the engine provides general 
mechanisms for managing process versions and we leave it to the 
integration layer / tooling around the engine to define particular 
behavior related to lifecycle management.

alex



Mime
View raw message