[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-22) TOSCA Versioning
[ http://tools.oasis-open.org/issues/browse/TOSCA-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30826#action_30826 ]
Derek Palma commented on TOSCA-22:
----------------------------------
It seems we are now talking about two things:
1) How to denote the version. This is an invariant attribute of the entity. I think it's better to explicitly denote it not just so we don't have to extract it from some string, but so we can constrain and reason over the domain of the version space. This would allow different types to have there own version domain that is appropriate for them and inequality predicates are easily handled.
2) How to reason over the version. Some set of predicates should be available for each version domain. We can probably get by with kind Tobias causes me to think about which is covered by most modern languages and packagers.
Regardless of the version value, the URI used to denote a ServiceTemplate should be unique (compared to the URI of another ServiceTemplate but different in some way) in the same scope. Also the version value will be generally human readable and hence human meaningful.
It seems like we are not differentiating concisely between type verisioning versus instance versioning. Types (Node and Relation) are different if their schema changes (evolves) and we could denote these with versions. There is the basic question of whether you even allow type versioning at all by just forcing creation of a new type since you are taking the old type and denoting it with typeName + version anyway. In type systems where types are denoted with URIs (XML style encoded metamodels) even though the URI has a version number in it, the types denoted with that URI are really completely different that types denoted with the previous URI. I.e. you can't really make any assumptions about two consecutive versions of the same types.
This leaves instance (templates) versioning which is what I presume Bryan and Tobias are talking about.
> TOSCA Versioning
> ----------------
>
> Key: TOSCA-22
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-22
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: Improvement
> Components: Spec
> Reporter: Paul Lipton
> Assignee: Tobias Kunze
>
> Originally sub-issue 7 in TOSCA-20, called "NodeTypes should have a "Version" field ," no consensus was made on this at the 6/7/12 meeting. This lack of consensus was probably the result of unclear scope. Reconsidering on 6/14, the TC has decided that the scope of the versioning issue is greater than this, e.g., do we mean of model / version of entities / etc., and requests Tobias, as original proposer of the "seed issue" in TOSCA-20, to take ownership of this issue.
> See minutes from both these meetings. Others are invited to contribute/comment, of course.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]