[OASIS Issue Tracker] (OSLCCCM-36) Need to distinguish in-progress change set from delivered/committed one

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCCM-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66728#comment-66728 ] 

Nick Crossley commented on OSLCCCM-36:
--------------------------------------

Here's a completely different approach to be discussed:

Create a change set:
POST to an oslc_config:openChangesets LDPC on the parent stream
Post MUST fail if dcterms:identifier is passed, and a change set with that identifier already exists in this same LDPC
Spec does NOT DEFINE what happens if the POST contains a dcterms:identifier which is the same as an existing changeset used in some other stream

Show all change sets open for a stream
GET the oslc_config:openChangesets LDPC; all open change sets based on a stream MUST appear in this LDPC

Cancel a change set
DELETE the change set; it will be removed from any/all open and delivered change set LDPCs of which it is a member
(this does not imply that all trace of the change set is deleted internally - an application may keep an audit record of this canceled change set, and the server MAY allow resurrection by POSTing it back to some stream’s oslc_config:openChangesets LDPC.)
Servers MAY disallow DELETE on change sets that have been committed or delivered anywhere

Committing or delivering a change set, and distinguishing open change sets
On committing or delivering a change set, the server MUST remove that change set from the oslc_config:openChangesets if the change set was previously open, MUST add the change set to the oslc_config:deliveredChangesets LDPC of the target stream and MUST add the target stream to the oslc_config:deliveredTo LDPC of the change set.
Implementation note: since the specification does not define any PUT or POST operations on the oslc_config:deliveredChangesets or oslc_config:deliveredTo LDPCs, those containers may be implemented as dynamic queries run on request, with the implementation storing this information in one place.
A change set is considered open if it has no oslc_config:deliveredTo LDPC, or if that LDPC exists but is empty.

Baselines
When a baseline is created, the server MUST copy the contents of the oslc_config:deliveredChangesets LDPC of the stream to the same property on the new baseline, and MUST then empty that LDPC on the stream - that is, the oslc_config:deliveredChangesets LDPC of a stream contains only the change sets committed or delivered since the previous baseline - and hence the oslc_config:deliveredChangesets LDPC of a baseline also contains only the change sets delivered since its previous baseline, and so forth.

Modifications to changeset LDPCs
The spec will not define any semantics for modifying change set LDPCs other than the initial creation via POST to an oslc_config:openChangesets LDPC on the parent stream.

The above does not include the date/time committed property - that could be added if desired.

> Need to distinguish in-progress change set from delivered/committed one
> -----------------------------------------------------------------------
>
>                 Key: OSLCCCM-36
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-36
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Improvement
>          Components: Configuration Management
>            Reporter: David Honey
>            Assignee: Nick Crossley
>
> The current change management spec describes the resource shape for a oslc_config:ChangeSet. We have a requirement to distinguish an in-progress change set from a delivered/committed change set. We have been using the deprecated oslc_config:mutable property. A value of "false"^^xsd:boolean meant in-progress, and "true"^^xsd:boolean meant delivered. However, this usage is a little obscure and not documented for in the spec for this specific use case.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)