Changes between Version 12 and Version 13 of CMDI 1.2/Lifecycle management

Timestamp:

01/16/14 13:56:41 (10 years ago)

Author:

mwindhouwer

Comment:

--

CMDI 1.2/Lifecycle management

@@ -127 +127 @@
 
 When C2 is deprecated and a new version is available, this information should in some way be propagated to all its containing components and profiles. If not, both C1 and P1 will remain available in public. Any users selecting P1 (or another profile containing C2) for their metadata will then also choose the deprecated C2, without knowing that it is so. I really think that when a component is "replaced" by a new version, any "new" use of the old version should be strongly discouraged.
-   * Menzo: This cascade could easily lead to lot of 'suddenly' problematic components and profiles if a frequently used component is deprecated, e.g., deprecation of cmd-language would cause a large ripple. I think its better to asses the lifecycle status per component, i.e., reuse of C1 is still fine even when its reuses the deprecated component C2. This is due to the fact that the owner of C2 can have very specific reasons for deprecation, which are not shared by the owner of C1. These conflicts of interest shouldn't prevent existing nesting from working, hence no cascades. The CR does try to discourage new nesting of deprecated components, but even that should still be possible.
-* Information about status change to existing component users: It might be nice to have some kind of subscription service, by which metadata creators, when choosing profiles for their metadata, get the opportunity to subscribe to notification whenever the profile or any of its components change status.
-   * Menzo: Would indeed be a nice CR function.
+ Menzo: This cascade could easily lead to lot of 'suddenly' problematic components and profiles if a frequently used component is deprecated, e.g., deprecation of cmd-language would cause a large ripple. I think its better to asses the lifecycle status per component, i.e., reuse of C1 is still fine even when its reuses the deprecated component C2. This is due to the fact that the owner of C2 can have very specific reasons for deprecation, which are not shared by the owner of C1. These conflicts of interest shouldn't prevent existing nesting from working, hence no cascades. The CR does try to discourage new nesting of deprecated components, but even that should still be possible.
+
+Information about status change to existing component users: It might be nice to have some kind of subscription service, by which metadata creators, when choosing profiles for their metadata, get the opportunity to subscribe to notification whenever the profile or any of its components change status.
+
+ Menzo: Would indeed be a nice CR function.
 
 ----