[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-121) Allow alternative skew resolution algorithms
[ https://issues.oasis-open.org/browse/OSLCCORE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=69168#comment-69168 ]
David Honey commented on OSLCCORE-121:
--------------------------------------
If component skew is present, but different collaborating domain tools used different algorithms, one problem will be the resolution of version could be different between the tools. For example, a requirement resolved for one LC might be incompatible with a test case that validates that requirement. If we want to be less prescriptive, I think it worth stating that co-operating tools SHOULD use similar algorithms.
> Allow alternative skew resolution algorithms
> --------------------------------------------
>
> Key: OSLCCORE-121
> URL: https://issues.oasis-open.org/browse/OSLCCORE-121
> Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
> Issue Type: Improvement
> Components: Configuration Management
> Reporter: Nick Crossley
> Assignee: Nick Crossley
>
> In the current draft, a Config Mgmt server MUST provide a version resolution process using a first match in a depth-first search starting at the top of the configuration context, and MAY provide a way to find all matches.
> Neither of these two algorithms necessarily meets client needs. No implementations exist for the All Matches approach.
> The specification is overly precise, and its precision is not useful in this case.
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]