Need to distinguish in-progress change set from delivered/committed one

[oslc-bot]

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. One implementation has 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.

---

Migrated from https://issues.oasis-open.org/browse/OSLCCORE-99 (opened by @ndjc; previously assigned to @ndjc)

[oslc-bot]

@ndjc: In the CCM TC meeting on August 10th, David raised the concern that having the oslc_config:deliveredChangesets LDPC of a baseline contain only the change sets delivered since the previous baseline, and having no cumulative list of delivered change sets since the last major release, might be a problem for the common query "what have I fixed or added in this release?".

We could address that by allowing another LDPC oslc_config:cumulativeChangesets plus a new predicate oslc_config:cumulativeChangesetBaseline. Both these would be OPTIONAL properties. If either one was present, so must the other one. The change sets in the cumulativeChangesets LDPC would be the cumulative contents of the oslc_config:deliveredChangesets LDPCs of all baselines since the first baseline taken after the oslc_config:cumulativeChangesetBaseline through the subject baseline itself.

This approach would avoid the problem of defining an LDPC that could grow without bounds.

[oslc-bot]

@ndjc: Geoff Clemm would rather see a "compare" operation, rather than introduce a property like oslc_config:deliveredChangesets that just introduces a compare to some specific ancestor baseline.

[ndjc]

QUESTION: Do we need to resolve this before PS 01? Or at all?

[berezovskyi]

@DavidJHoney is this related to #528 and does it need to be addressed?