OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (CAMP-172) consider specifying a generic 'version' characteristic for use in ServiceSpecifications

     [ https://issues.oasis-open.org/browse/CAMP-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Otto updated CAMP-172:

    Proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53542/camp-spec-v1.1-wd43-issue172.doc  (was: Rough Proposal: Define a generic 'version' characteristic that can be used to describe the version of any service. Figure out the semantics that this characteristic needs to support (e.g. bounded comparisons) and decide on a syntax to implement those semantics. Look to Maven and OSGI for examples.)

> consider specifying a generic 'version' characteristic for use in ServiceSpecifications
> ---------------------------------------------------------------------------------------
>                 Key: CAMP-172
>                 URL: https://issues.oasis-open.org/browse/CAMP-172
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Adrian Otto
> 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.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]