On Feb 17, 2010, at 10:44 AM, Larry O'Leary wrote:
Well there are two possibilities here. One is that there is a
roll-back. The other is that a new version of a VDB has been chosen as
the default but some of the organization is not ready to use the newer
version. In which case they would modify their clients to use the
previous version until they are ready to use the new one.
So, in the "roll-back" scenario, the change is transparent to the
clients while in the "not-ready-to-upgrade" scenario the administrative
change is placed on the client. These are the two cases we have with
legacy customers.
Maybe I'm misunderstanding, but I don't believe your "new version"
scenario makes practical sense. If an organization is implementing a new version and not
ready to force that change on certain applications, departments, etc., wouldn't they
want just that - no change to those areas? They're likely not going to impose the
need to change a slew of existing clients to use the old VDB just to enable new clients to
use the previous VDB name. Rather, they'd want to deploy the new VDB with a new name
that only the new clients use. Then migration to the new VDB name for other clients could
be easily scheduled and managed. Seems like the alternative would be a change-control
nightmare.
Thanks,
JPAV