Component and profile versioning/deprecation

[twagoo]

Note: #571 covers support for public drafts (publicly visible private components), a subset of the functionality described here, without the lifecycle status properties specified in CMDI 1.2

This enhancement should enable an owner of a component to designate a new component or profile as the new version of an existing a component, marking the existing version deprecated.
There will (at least initially) be no mechanism to deal with backwards compatibility, i.e. published components will remain unchanged but users will be strongly encouraged to use to the new version. The status will be represented in the XML/XSD of the profile (see #146).

This is the first and most important step after the required general component schema update in implementing the Component Lifecycle Management features of CMDI 1.2.

Also take note of the envisioned set of views that strongly relate to this (and the additional option to mark development components for review). See ComponentVersioning#Viewsworkspacesandregistries.

[twagoo]

Adding to this:

• When a component is derived from another one, this relation should be stored as well. See request below.

On 2/6/12 16:00 , Christina Hoppermann wrote:

What's even more important for us is a possibility of flagging components/profiles, both for indicating relationships (e.g. saying that component A was derived from component B by adding another data category, etc., highlighting that they basically share a common core) and for versioning components (e.g. when we create a component A, make it public and recognize after some time that we need to add some more data categories or even only need to change a cardinality, resulting in a component A'). This is the main reason for us not publishing our profiles/components, as we do not have a possibility of indicating aspects like these and we still need to be able to edit components/profiles within the development process, as we constantly get new resource types for which we need to create metadata profiles. Anyway, I think this issue could already be on your todo-list, so please ignore this paragraph if it is the case.

[twagoo]

There now is an extended proposal for this (work in progress) at ComponentVersioning.

[twagoo]

Proposal CMDI dev meeting 2012/4/12: status property = private -> development -> public -> deprecated/superseded. Allow multiple successors.

Question: who should be allowed to change status of a component? Probably just owner and admin.

[twagoo]

• A list of deprecated components should be available by request through the webservice
• Deprecation and succession will require a reason (for deprecation) or comment (for new version)

[twagoo]

Relates to, and changes may have implications for #146

Also touches #143

[twagoo]

r1992 adds the ComponentStatus enumeration that replaces the boolean isPublic property. For now there are two statuses 'Development' (this is currently called 'Private'), and 'Public'. Statuses 'Private' and 'Deprecated' are to be added at a later stage.

[twagoo]

r3035 reshuffles the statuses; now we have in ComponentStatus.java:

    /**
     * Private mode, editable non-public
     */
    PRIVATE(false, true),
    /**
     * Development mode, editable and publicly visible
     */
    DEVELOPMENT(false, true),
    /**
     * Published mode, non-editable and publicly visible
     */
    PUBLISHED(true, false),
    /**
     * Deprecated mode, non-editable and not publicly listed
     */
    DEPRECATED(false, false);

[twagoo]

I have updated the section ComponentVersioning#Design in the wiki

[Twan Goosen]

moved to 1.15, will be split up

[Twan Goosen]

added ref to #571

[Twan Goosen]

George has left

[Twan Goosen]

​https://github.com/clarin-eric/component-registry-rest/issues/12 (back end) and ​https://github.com/clarin-eric/component-registry-front-end/issues/53 (front end)

[Twan Goosen]

Ticket retargeted after milestone deleted