| Version 2 (modified by , 10 years ago) (diff) |
|---|
This page is a subpage of CMDI 1.2
Lifecycle Management in CMDI 1.2: Executive summary
This page provides an executive summary of the issue and proposed solution fully described in CMDI 1.2/Lifecycle management.
Issue description
Once published, a component gets 'frozen' so that all instantiations can rely on it not changing and thus are guaranteed to retain their validity. Also, after a certain 'cooling down' period, published components cannot be removed from the public space (except by administrators). This leads to issues when changes in the domain or new insights need to be incorporated in the component. One can create a new component based on an existing one, extend it and finally make it public. But as a versioning mechanism this has a number of limitations:
- There is no reliable way to find out who is instantiating specific components, so the users are unknown and cannot simply be informed
- The old component cannot be deleted, so new users might accidentally start using the old one
- All of this is very informal, and requires a lot of work with few guarantees
A formal way of deprecating components and specifying versioning information would solve these issues. In such a workflow, the owner of a component can:
- Create a new component (e.g. by copying the existing component as a basis)
- Edit until satisfied
- Publish into public space
- Deprecate the 'precursor' component
- Designate the new component as 'successor' to the old one
This information needs to be communicated to the client that request the deprecated component, and remove it from the public list. Clients should of course still be able to use the deprecated component since it is not always possible to upgrade.
