Changes between Version 8 and Version 9 of ComponentVersioning

Timestamp:

08/21/13 12:52:03 (11 years ago)

Author:

twagoo

Comment:

added section 'Considerations for tools' and some other minor changes

ComponentVersioning

@@ -1 +1 @@
 The purpose of this page is to come to a design for an extension of the [[ComponentRegistryAndEditor|ComponentRegistry]] that will enable '''versioning''' and '''deprecation''' of components and profiles.
+
+[[PageOutline(1-3, , inline)]]
 
 = Component versioning =
@@ -95 +97 @@
 }}}
 
+== Considerations for tools further down the chain ==
+
+=== Metadata editing ===
+
+Deprecated versions of profiles should not be advertised to the user (e.g. should not appear in the profiles list in Arbil) but there should be no restriction in using them (i.e. the can still be added by their schema URL) and existing metadata will be untouched,. The metadata editor however could indicate the deprecated status of used profiles, including (non-obtrusive) notifications about the status of the profile the metadata being worked on is based on. For example, the icon shown for the metadata documents could reflect the state of the profile. Similarly, the list of active profiles in Arbil could mark those profiles in the list that are marked as deprecated. In case a successor is available, the editor should notify the user about that as well and ideally offer to load that profile instead (or in addition). Automatic upgrading to the new version should not happen, but assisting the user in attempting a migration could be considered (here the user should be warned about potential implications on the semantics of the existing values as a result!).
+
+=== Search & catalogue tools ===
+
+Search tools that explicitly distinguish between profiles in the user interface could apply clustering with respect to different versions of the same profile (traversing the succession chain). In those cases where profile names are shown, it could make sense to show the status of the profile (e.g. under development, deprecated) if this is considered to be of interest to the user.
+
 == Notes ==
 
+* A specific version of a profile will always keep its unique profile ID
 * Only owners (and admins) can change the status of a component (as is the case with publishing now)
 * Deprecation and succession will require a reason (for deprecation) or comment (for new version)
@@ -103 +116 @@
 
 * Should 'bi-directional' versioning information be provided or just successors? (should a successor component refer to its precursor?)
+ * Consensus seems to be: no
 * 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? 
+ * Consensus seems to be: no special support, this is only relevant in the context of inheritance
+* ...