| | 9 | 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. |
| | 10 | 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: |
| | 11 | |
| | 12 | * There is no reliable way to find out who is instantiating specific components, so the users are unknown and cannot simply be informed |
| | 13 | * The old component cannot be deleted, so new users might accidentally start using the old one |
| | 14 | * All of this is very informal, and requires a lot of work with few guarantees |
| | 15 | |
| | 16 | A formal way of deprecating components and specifying versioning information would solve these issues. In such a '''workflow''', the owner of a component can: |
| | 17 | |
| | 18 | 0. Create a new component (e.g. by copying the existing component as a basis) |
| | 19 | 0. Edit until satisfied |
| | 20 | 0. Publish into public space |
| | 21 | 0. Deprecate the 'precursor' component |
| | 22 | 0. Designate the new component as 'successor' to the old one |
| | 23 | |
| | 24 | 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. |
| | 25 | |
