dshoneisda
commented
1 year ago I think this works. We should finalise in the steering group and note that some of these may not be mandatory, but expedient e.g. the domain wg sign off
Closed chrisisla closed 11 months ago
dshoneisda
commented
1 year ago I think this works. We should finalise in the steering group and note that some of these may not be mandatory, but expedient e.g. the domain wg sign off
chrisisla
commented
11 months ago The PR documentation should also include a section that details and explains any changes that are backwardly incompatible. This will greatly assist people working with the model, and can be accumulated into the production level release notes.
Thanks @lolabeis for the suggestion!
lolabeis
commented
11 months ago The PR documentation should also include a section that details and explains any changes that are backwardly incompatible.
By "PR documentation", we propose that these backward-incompatible changes be documented in a specific Backward- incompatible changes section in the PR's release notes. The existing detailed What is released? section could be broken-down between that section and a section that focuses on new additions.
The backward-incompatible section should include documented examples for implementors to remap CDM objects that may have been persisted using the prior version, with references to sample files included in the CDM distribution.
A good retrospective example to illustrate this approach is the recent pair of "price refactoring" PRs which contain fundamental structural changes to the core CDM component Price:
Under the proposed framework, the release notes would have contained the following section:
Backward-Incompatible Changes
MultiplierOfIndexValue from PriceTypeEnumGrossOrNetEnum:CleanOrDirtyPriceEnumCapFloorEnumSpreadTypeEnumPriceExpressiongrossOrNet from type CashflowTypeSample Impact
eqs-ex01-single-underlyer-execution-long-form.json: NET has been removed from the asset price and ArithmeticOperator -> Add is used instead of spreadType -> Spread in the interest rate priceFrom:
"priceQuantity" : [ {
"price" : [ {
"value" : 37.44,
"priceExpression" : {
"grossOrNet" : "NET",
"priceType" : "ASSET_PRICE"
}
...
} ]
...
} ],
"priceQuantity" : [ {
"price" : [ {
"value" : 0.0020,
"priceExpression" : {
"priceType" : "INTEREST_RATE",
"spreadType" : "SPREAD"
}
...
} ]
...
} ]
To this:
"priceQuantity" : [ {
"price" : [ {
"value" : 37.44,
"priceType" : "ASSET_PRICE"
...
} ]
...
} ],
"priceQuantity" : [ {
"price" : [ {
"value" : 0.0020,
"arithmeticOperator" : "ADD",
"priceType" : "INTEREST_RATE"
...
} ]
...
} ]
ird-ex22-cap.json: uses ArithmeticOperator -> Min instead of CapFloor -> CapFrom:
"price" : [ {
"value" : 0.06
"priceExpression" : {
"capFloor" : "CAP",
"priceType" : "INTEREST_RATE"
}
...
} ]
To this:
"price" : [ {
"value" : 0.06,
"arithmeticOperator" : "MIN",
"priceType" : "INTEREST_RATE"
...
} ]
ird-ex27-inverse-floater.json: there are now 2 price objects, that use respectively ArithmeticOperator -> Add instead of SpreadType -> Spread and ArithmeticOperator -> Multiply instead of PriceType -> MultiplierOfIndexValueFrom:
"tradableProduct" : {
"product" : {
"contractualProduct" : {
"economicTerms" : {
"payout" : {
"interestRatePayout" : [ {
"rateSpecification" : {
"floatingRate" : {
...
"floatingRateMultiplierSchedule" : {
"price" : {
"address" : {
"scope" : "DOCUMENT",
"value" : "price-1"
}
}
}
}
}
} ]
}
}
}
}
},
"tradeLot" : [ {
"priceQuantity" : [ {
"price" : [ {
"location" : [ {
"scope" : "DOCUMENT",
"value" : "price-1"
} ],
"value" : {
"unit" : {
"currency" : {
"value" : "USD"
}
},
"value" : -1.0,
"priceExpression" : {
"spreadType" : "SPREAD",
"priceType" : "MULTIPLIER_OF_INDEX_VALUE"
}
}
} ]
} ]
} ]
To this:
"tradableProduct" : {
"product" : {
"contractualProduct" : {
"economicTerms" : {
"payout" : {
"interestRatePayout" : [ {
"rateSpecification" : {
"floatingRate" : {
...
"spreadSchedule" : {
"price" : {
"address" : {
"scope" : "DOCUMENT",
"value" : "price-1"
}
}
},
"floatingRateMultiplierSchedule" : {
"price" : {
"address" : {
"scope" : "DOCUMENT",
"value" : "price-2"
}
}
}
}
}
} ]
}
}
}
}
},
"tradeLot" : [ {
"priceQuantity" : [ {
"price" : [ {
"location" : [ {
"scope" : "DOCUMENT",
"value" : "price-1"
} ],
"value" : {
"unit" : {
"currency" : {
"value" : "USD"
}
},
"value" : 0.085,
"arithmeticOperator" : "ADD",
"perUnitOf" : {
"currency" : {
"value" : "USD"
}
},
"priceType" : "INTEREST_RATE"
}
}, {
"location" : [ {
"scope" : "DOCUMENT",
"value" : "price-2"
} ],
"value" : {
"unit" : {
"currency" : {
"value" : "USD"
}
},
"value" : -1.0,
"arithmeticOperator" : "MULTIPLY",
"perUnitOf" : {
"currency" : {
"value" : "USD"
}
},
"priceType" : "INTEREST_RATE"
}
} ]
} ]
} ]
fx-ex03-fx-fwd.json: uses the new PriceComposite component with ArithmeticOperator -> Add, OperandType -> ForwardPoint and the baseValue and operand attributes for the values previously associated with SpreadType -> Base and SpreadType -> Spread, respectively.From:
"price" : [ {
"unit" : {
"currency" : {
"value" : "USD"
}
},
"value" : 0.9175,
"perUnitOf" : {
"currency" : {
"value" : "EUR"
}
},
"priceExpression" : {
"priceType" : "EXCHANGE_RATE"
}
}, {
"unit" : {
"currency" : {
"value" : "USD"
}
},
"value" : 0.9130,
"perUnitOf" : {
"currency" : {
"value" : "EUR"
}
},
"priceExpression" : {
"priceType" : "EXCHANGE_RATE",
"spreadType" : "BASE"
}
}, {
"unit" : {
"currency" : {
"value" : "USD"
}
},
"value" : 0.0045,
"perUnitOf" : {
"currency" : {
"value" : "EUR"
}
},
"priceExpression" : {
"priceType" : "EXCHANGE_RATE",
"spreadType" : "SPREAD"
}
} ]
To this:
"price" : [ {
"unit" : {
"currency" : {
"value" : "USD"
}
},
"value" : 0.9175,
"composite" : {
"arithmeticOperator" : "ADD",
"baseValue" : 0.9130,
"operand" : 0.0045,
"operandType" : "FORWARD_POINT"
},
"perUnitOf" : {
"currency" : {
"value" : "EUR"
}
},
"priceType" : "EXCHANGE_RATE"
} ]
In order to improve the quality and consistency of Issues and Pull Requests the suggestion has been made that we make use of the Templates available in github.
I propose creating a new general Pull Request template that will be built around the principles and suggestions outlined in the Steering WG on 10th October. The requirements are that a Pull Request must:
Where possible the use of checkboxes is recommended to make it easier for contributors to confirm that they have performed the required tasks. Where a checkbox is ticked then evidence that the work/item has been undertaken will be required.
For example, if the checkbox for "Release Notes" is ticked then the owner of the Pull Request must ensure that the Release Notes are attached. In some cases the Build and Release process can automatically confirm the existence of these items, but this will not be possible in all cases.
This Issue is only for an initial general Pull Request template. Additional templates can be created in the future if we feel we have different requirements for different types or Pull Requests e.g. model changes, technology changes, documentation changes.
Please provide any feedback you have as a comment to this Issue.