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
