Changes between Version 21 and Version 22 of CMDI 1.2/Lifecycle management
- Timestamp:
- 02/12/14 13:25:11 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CMDI 1.2/Lifecycle management
v21 v22 59 59 60 60 This optional element points to the direct successor of the component. It indicates a succession relation and is only meaningful if the values of ''Status'' is ''Deprecated''. 61 The value should be the full URI of the successor component. Only a single successor can be specified. 61 The value should be the full URI of the successor component. Only a single successor can be specified. Status of the final component in a successor chain should be "production". 62 62 63 63 ==== Derived from header (optional) ==== … … 77 77 Status can be mapped to views, see [[ComponentVersioning#Viewsworkspacesandregistries|ComponentVersioning]]. Besides that, the Component Registry will have to provide inputs for the user to manage the status of their own components. Part of the information gathering can be automated (!DerivedFrom). 78 78 79 Information about impact of status change should be readily available to owner, especially when deprecating. For example, number of components in which the component-to-be-deprecated is included. 80 79 81 ====== Status filtering ====== 80 82 The browsing mode of the Component Registry, as well as the REST service through which the list of components and profiles can be requested, needs te be filterable. Currently, there is a switch between private and public components. With the proposed set of status values, this needs to be revisited. A suitable paradigm seems to consist of two main views: components visible by the logged in user and components visible to the public - there may be an overlap. Then the following filter toggles are available for the latter view, both OFF by default: … … 87 89 The default filter settings described above are the first and most important step in discouraging users to use non-production components. In addition, warnings can be given at two stages: 88 90 * visually but non-obtrusive in the listing (e.g. warning icons on rows that represents the deprecated or development components) 89 * through a modal dialogue when a user actively decides to include such a component (through 'edit as new' or by dragging it into a component being edited) 91 * through a modal dialogue when a user actively decides to include such a component (through 'edit as new' or by dragging it into a component being edited). Should be checked recursively, i.e. also give warning whenever the the selected component '''contains''' deprecated components. 92 * visually in single component view (e.g. warning icon (same as in listing)beside any deprecated subcomponents in the lower pane of CR) 90 93 91 94 ====== Automatic 'derived from' ====== … … 93 96 When a component is created by selecting an existing component and clicking 'edit as new', the !DerivedFrom header value should automatically be populated with the ID of the original component. However it should be possible for the user to remove this or put another ID in place (but this should clearly be an advanced option!). 94 97 95 ====== Owner notifications ======98 ====== Owner/user notifications ====== 96 99 The following automatic notifications would be nice to have: 97 100 98 101 * Notification of component owners when a component referenced in one of their components becomes deprecated 99 102 * Notification of component owners when a derivative of one of their components is created 103 * Notification of component subscribers when any of the subscribed components become deprecated 100 104 101 105 RSS or e-mail could be used as a means of notification
