[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=59266#comment-59266 ] 

Mike Norman commented on CAMP-182:
----------------------------------

I have a slightly different perspective on this. In our world we extend CAMP so that the Platform is not the top of the tree, we have a notion of an Enterprise that sits above that and to which the Platform belongs. We need an API version for both the Enterprise and the Platform, as well as various other entities that belong to the Enterprise (and which link back into entities inside the Platform). So the Platform Endpoint is a bit irrelevant to the overall picture. 

From the perspective of a client consuming the API we retrieve the metadata of the Resource by an extension to the API which places a reference to the TypeDefinition (and thereby its AttributeDefinitions ) into each Resource (apart from the List resources).  The logical thing to do is have the TypeDefinition have a many-to-many relation to APIVersions and Extensions, which both belong to the Enterprise.  If you do this, you can lose the platformEndpoint, because the client can ask each and every resource what versions of the API it supports.  This then allows arbitrary decoupling into variously-versioned microservices within the implementation. as per my previous JIRA [CAMP-177].  I will explain in a bit more detail on that Jira what the use cases are.

One thing that I woudl say, is that we are working with a data model that is roughly 50% extensions, and we are building a client that treats the core model and its extensions in an equivalent way, so we are very keen that there are generic rules about how the API is constructed from the underlying domain model, and that there are no "special cases".


> 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)