Versioning in Rating Management

Rate flow

Logic defined in Gosu code in the rate flow has no inherent versioning other than source control strategies. Avoid versioning in the rate flow. Versioning in the rate flow must be done with conditional logic, which can become difficult to support.

Rate tables

Versioned by their inclusion in a particulate edition of a rate book. Rate books are selected by the rate flow implementation based on date criteria from the policy data and the values set in the rate book content.

Rate routines

Versioned outside the rate book. The rate book includes a specific version of the rate routine.

Rate routine functions

Functions are not versioned in rate books and the example implementations do not include versioning. Suggested approaches to handle this issue are:

• No versioning – Some functions, such as functions that do not affect premium calculations, do not require versioning. For example, a function for logging.
• Versioning through method parameter – In the function definition, include a parameter for version number. The rate routine passes in the version number when it calls the function. For example, mySampleFunction(1.0, Vehicle). It is up to your implementation of the function to run the appropriate code for that version.
• Versioning by changing the name of the function – Create a new version of the function name by creating a new function with a version string or qualifier appended to the name. For example, name the next version of getYoungestDriver function getYoungestDriver_v1. Or name a version for motorcycles getYoungestDriverForMotorcycles.
• Versioning the implementation class – This is the most complex approach. Replace the mechanism that creates the function container class with an implementation that includes awareness of the version required, possibly using the rate book edition as a parameter. This approach requires modification of Gosu classes that implement the rating engine.