Changes between Version 5 and Version 6 of ComponentVersioning

Timestamp:

04/10/12 13:57:39 (12 years ago)

Author:

twagoo

Comment:

Written intro/use case

ComponentVersioning

@@ -8 +8 @@
 * '''Versioning''' refers to the precursor/successor relation that may exists between two components. It does not imply a structural or functional extension or inheritance, i.e. the structure of the precursor component does not put any constraints on the structure of the successor relation; no assumptions about the structure of the' one can be made on basis of the structure of the other. Versioning does not imply deprecation (see below) of the precursor.
 * '''Deprecation''' refers to a state in which a component is no longer 'advertised' by the registry (it will not appear in the list of published components) and will be explicitly marked as such to the client. However it will still be accessible by its URI so that instances based on deprecated components will remain valid. Apart from this, the properties of published components apply. Deprecation can optionally be combined with versioning.
+
+== !Introduction/Use case ==
+
+The goal of designing components and profiles in the !ComponentRegistry is to eventually make them available in the public space so that everyone can use them as a basis for metadata creation. However, 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). 
+
+Robust though this practice may be, it leads to issues when changes in the domain, or simply new insights, need to be incorporated in the component. It is easy to create a new component based on an existing one, extend it and finally make it public. But then one would like to communicate to the users of the component that they should use the new component for new metadata (possibly even convert existing metadata) instead of the old one. However, there are a few problems:
+
+* 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. The owner of a component can simply:
+
+0. Create a new component (typically copying the existing component as a basis)
+0. Edit until satisfied
+0. Publish into public space
+0. Deprecate the 'precursor' component
+0. Designate the new component as 'successor' to the old one
+
+The !ComponentRegistry can then provide this information to all clients 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.
 
 == Design ==
@@ -70 +90 @@
 * Should 'bi-directional' versioning information be provided or just successors? (should a successor component refer to its precursor?)
 * What to do with many-to-many relations in versioning? (merging and branching of components)
+* Would it be useful to be able to review the versioning history of specific components in a user friendly overview?