[OASIS Issue Tracker] (CAMP-182) CAMP specification versioning

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

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

Gilbert Pilz commented on CAMP-182:
-----------------------------------

Normally specifications like CAMP define the backwards and forwards compatibility requirements based on major and minor version changes. For example, we could say that, within a CAMP major version, all CAMP versions are backwards compatible with the previous versions. For example, it must be possible to successfully POST a CAMP 1.x plan file to a CAMP 1.y "plans" resource (where y > x). Likewise a CAMP 1.x client must be able to do a GET on a CAMP 1.y resource and not have their code break due to the absence of attributes, etc. (though it may be possible for CAMP 1.y to add attributes that didn't exist in CAMP 1.x - we'd have to discuss this).

However, because CAMP 1.1 defines the "platform_endpoints" collection resource and the "platform_endpoint" resource, we have the option of sidestepping this issue and saying that every CAMP version is not necessarily backwards compatible with any other CAMP version. If you are a CAMP 1.x client and want to work with a CAMP provider, you need to navigate platform_endpoints->platform_endpoint->platform for CAMP 1.x. If the provider doesn't have a platform_endpoint resource for CAMP 1.x you are out of luck.

I'm not sure if the later is actually a good idea. One thing it does is change the nature of the platform_endpoints and platform_endpoint resources from "something you might want to do if you support multiple versions of CAMP" into "something you have to do to support multiple versions of CAMP". Suppose a provider supported CAMP 1.1, CAMP 1.2, and CAMP 1.3. If 1.3 were backwards compatible with 1.2 and 1.1, and 1.2 were backwards compatible with 1.1, this provider could support all three versions with a single tree of resources rooted in a single "platform" instance. If every version were independent, this provider would need three "platform" instances, each with their own tree of resources (which may or may not be handled by common code). Is "bushyness of the resulting resource tree" a valid design consideration?



> CAMP specification versioning
> -----------------------------
>
>                 Key: CAMP-182
>                 URL: https://issues.oasis-open.org/browse/CAMP-182
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Anish Karmarkar
>            Priority: Minor
>
> We have CAMP 1.1 Committee Spec (CS). We are waiting for two implementations to move it to OASIS Specification (OS). As new issues are filed and we resolve them the spec may change. What is our versioning scheme? Does backward/forward compatibility affect our versioning scheme. As a point of reference, CAMP 1.0, which was the initial submission, is not compatible with CAMP 1.1 (backward or forward, for the client side or the provider side).



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