Uploaded image for project: 'OASIS Cloud Application Management for Platforms (CAMP) TC'
  1. OASIS Cloud Application Management for Platforms (CAMP) TC
  2. CAMP-172

consider specifying a generic 'version' characteristic for use in ServiceSpecifications

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Spec
    • Labels:
      None

      Description

      As of PR2, CAMP is silent about any characteristics that might appear in the 'characteristics' array of a ServiceSpecification. Although we can't know all the aspects that might be used to characterize various services, we do know that all services have a version and that this version is usually important to consumers of that service. Experience has shown that Consumers often want to specify things like "this artifact requires version 2.3 of this service or greater" or "this artifact works with any 2.x version (but not 1.x nor 3.x)". If we force every CAMP Provider to independently implement versions themselves, the chance of any two Providers implementing the same syntax and semantic is small. This guarantees that Plans will not be portable across CAMP implementations.

        Attachments

          Activity

          Hide
          dpalma Derek Palma (Inactive) added a comment -

          Maven's version ranges are suitable for matching and well proven.

          http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

          http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html

          <major_version>.<minor_version>.<fix_version>[.<qualifier>[-<build_version] ]
          • major_version: is a required integer value greater than or equal to 0 (zero)
          • minor_version: is a required integer value greater than or equal to 0 (zero).
          • fix_version: is a required integer value greater than or equal to 0 (zero).
          • qualifier: is an optional string that indicates a named, pre-release version of the associated code that has been derived from the version of the code identified by the combination major_version, minor_version and fix_version numbers.
          • build_version: is an optional integer value greater than or equal to 0 (zero) that can be used to further qualify different build versions of the code that has the same qualifer_string.

          Show
          dpalma Derek Palma (Inactive) added a comment - Maven's version ranges are suitable for matching and well proven. http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html <major_version>.<minor_version>.<fix_version>[.<qualifier> [-<build_version] ] • major_version: is a required integer value greater than or equal to 0 (zero) • minor_version: is a required integer value greater than or equal to 0 (zero). • fix_version: is a required integer value greater than or equal to 0 (zero). • qualifier: is an optional string that indicates a named, pre-release version of the associated code that has been derived from the version of the code identified by the combination major_version, minor_version and fix_version numbers. • build_version: is an optional integer value greater than or equal to 0 (zero) that can be used to further qualify different build versions of the code that has the same qualifer_string.
          Hide
          gilbert.pilz Gilbert Pilz (Inactive) added a comment -

          What about operators? It seems to me that, if "tV" is the target version expressed by the characteristic, we need to be able to express either:

          a.b.c <= tV <= d.e.f

          where either a.b.c. or d.e.f may be absent (but not both)

          or:

          tV == g.h.i

          I'm trying to figure out how "qualifier" figures into these comparisons.

          Show
          gilbert.pilz Gilbert Pilz (Inactive) added a comment - What about operators? It seems to me that, if "tV" is the target version expressed by the characteristic, we need to be able to express either: a.b.c <= tV <= d.e.f where either a.b.c. or d.e.f may be absent (but not both) or: tV == g.h.i I'm trying to figure out how "qualifier" figures into these comparisons.
          Hide
          martin.chapman Martin Chapman (Inactive) added a comment -

          from 27th May 2014:

          MOTION: m/Gil s/Tom to open CAMP-172 as a P2 Issue
          No objections
          Motion is carried by UC

          Show
          martin.chapman Martin Chapman (Inactive) added a comment - from 27th May 2014: MOTION: m/Gil s/Tom to open CAMP-172 as a P2 Issue No objections Motion is carried by UC
          Hide
          adrian.otto Adrian Otto (Inactive) added a comment - - edited
          Show
          adrian.otto Adrian Otto (Inactive) added a comment - - edited I have added a proposal link in the issue metadata: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53545/camp-spec-v1.1-wd43-issue172-r1.doc
          Hide
          martin.chapman Martin Chapman (Inactive) added a comment -

          from 9th July 2014:
          Motion: m: Adrian, s: Anish moves to resolve CAMP-172 with r1 proposal in JIRA: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53545/camp-spec-v1.1-wd43-issue172-r1.doc
          No Objections. CAMP-172 is resolved.

          Show
          martin.chapman Martin Chapman (Inactive) added a comment - from 9th July 2014: Motion: m: Adrian, s: Anish moves to resolve CAMP-172 with r1 proposal in JIRA: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53545/camp-spec-v1.1-wd43-issue172-r1.doc No Objections. CAMP-172 is resolved.
          Show
          gilbert.pilz Gilbert Pilz (Inactive) added a comment - Resolution applied to WD 44: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53597/camp-spec-v1.1-wd44.doc
          Hide
          martin.chapman Martin Chapman (Inactive) added a comment -

          Closed due to the following motion on 27th August 2014:

          Motion: Gilbert Pilz m/"I move that the TC approve submitting Cloud Application Management for Platforms Version 1.1 Working Draft 48 contained in https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53966/CSD05package.zip for 15 days public review and designate the PDF version of the specification as authoritative." s/Tom Rutt
          no discussion
          no objections
          motion carried

          Show
          martin.chapman Martin Chapman (Inactive) added a comment - Closed due to the following motion on 27th August 2014: Motion: Gilbert Pilz m/"I move that the TC approve submitting Cloud Application Management for Platforms Version 1.1 Working Draft 48 contained in https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53966/CSD05package.zip for 15 days public review and designate the PDF version of the specification as authoritative." s/Tom Rutt no discussion no objections motion carried

            People

            • Assignee:
              adrian.otto Adrian Otto (Inactive)
              Reporter:
              gilbert.pilz Gilbert Pilz (Inactive)
            • Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: