Skip to main content

Maintenance and release

Reviewing model changes​

Contributions are reviewed by the DRR Working Group

Review checklist​

Before starting to review a contribution, the reviewer should go through the following review checklist:

  • Review Pull Request to assert that:
    • Model changes fulfil the proposed design and use-case requirements
    • Mapping have been updated and output (JSONJSON JavaScript Object Notation. Text-based, language-independent format with key-value pairs (eg Name: Dave).) looks correct
    • Contributed model version is not stale and does not conflict with any recent changes
    • Changes are in accordance with DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. governance guidelines, including the change control guidelines in the change control guidelines page

Note: It is not yet possible to verify that mapping, validation and qualification expectations have been maintained by looking at the output of the Pull Request and DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. build only.

  • DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. build process completed with no errors or test failures
  • Review additional samples provided (if use-case is not covered by existing samples)
  • All model components positioned in the correct namespace
  • All model components have descriptions
  • Additional documentation provided, if necessary.
  • Release note provided

Any review feedback should be sent to the Contributor as required via Slack, email or in direct meetings.

Model maintenance and release​

After learning about how to edit the model, please refer to this section to learn more about its maintenance.

Introduction​

Before the Pull Request can be merged into DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data.'s main branch, some work is usually required by the reviewer to preserve the integrity of the model source code and of its downstream dependencies.

Post-review technical tasks​

A number of technical tasks may need to be performed on the Pull Request once it is approved:

  • Stale DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. version: Contribution is based on an old DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. version and model changes conflict with more recent changes. If the conflicting change is available in RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR., the contributor should be asked to update their contribution to the latest version and resubmit. If the conflicting change is not yet available in RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR., this merge will need to be handled by DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. reviewer.
  • Failed unit tests: Java unit tests in DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. project may fail due to problems in the contributed changes. Alternatively it may be that the test expectations need to be updated. The reviewer should determine the cause of the test failure and notify either the Contributor or work on adjusting the test expectations.
  • Code generation: Model changes may cause code generator failures (e.g., Java, C#, Scala, Kotlin etc.). In the unlikely event of code generation failures, these will need to be addressed by the reviewer.

The change can be merged into the main DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. code base only upon:

  • approval by DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. reviewers and/or DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. Architecture and Review Committee,
  • successful completion of all the above technical tasks, and
  • successful builds of DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. and all its downstream dependencies.

Releasing model changes​

Once the contributed model change has been merged, a new release can be built, tested and deployed. The reviewer will work with DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. Owners and the Contributor on a deployment timeline.

The following release checklist should be verified before deploying a new model:

  • Update DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. version number, using the semantic versioning format
  • Build release candidate, and test
  • Build documentation website release candidate, and test
  • Deploy release candidate and notify channels if need be
  • (Currently done at a later stage) Update the latest DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. version available in RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR.

Note: When the release process is handled through RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR. Deploy, the reviewer should contact the RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR. support team to request that deployment and discuss a timeline for the release.

Release build approval guidelines​

This section covers scheduling of minor, development, and patch releases, and approvals for all builds and releases.

Development release scheduling and approvals​

  • Development releases may be scheduled by the reviewers to optimize development resources, based on the queue of approved PRsPR Pull request
    • There is no particular desired/expected release frequency; releases may be cut as soon as there is an approved PRPR Pull request, or several PRsPR Pull request may be consolidated into a single release at the convenience of the reviewers and dev staff
    • Rationalerationale An optional explanatory note added to a `regulatoryReference` to clarify why the rule’s functional logic is written the way it is.: Development releases are expected to change in functionality, and getting changes out as quickly as practical is usually desirable.
    • Each development release shall require the approval of one reviewer once all the PRsPR Pull request are approved, and the test cases all pass successfully.
  • Development releases shall be reported in brief to the DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. WG and the DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. SWG

Major production release build and release approvals​

  • Major production releases will be scheduled by the DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. SWG as described above
  • Each major production release shall require the approval of two reviewers after the following are complete:
    • The scope of the major production release is finalized and ratified by the DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. SWG
    • All approved PRsPR Pull request for the major production release are complete
    • The DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. SWG reviews the final list of enhancements in the release and signs off on releasing the development version into production

Minor production release scheduling and approvals​

  • Minor production releases may be scheduled by the reviewers based on the queue of approved PRsPR Pull request
  • Minor production releases to introduce enhancements should be combined to minimize the number of production releases, targeting minor production releases to be issued around four weeks or so as long as there is a queue of approved PRsPR Pull request. (This frequency can be increased in times of urgent need for new functionality).
    • Rationalerationale An optional explanatory note added to a `regulatoryReference` to clarify why the rule’s functional logic is written the way it is.: Minimizing the number of production releases will help with supportability, by reducing the number of releases that end users wishing to remain current need to consider, and reducing communications overhead.
  • Each minor production release shall require the approval of two reviewers.
  • Minor production releases shall be reported in brief to the CRWG and the SWG,
  • A roadmap of anticipated minor production releases shall be reported by the reviewers to the DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. WG based on PRsPR Pull request that are in process.

Production patch release scheduling and approvals​

  • Production patch releases to correct defects without releasing new functionality may be scheduled by the reviewers based on the presence of approved defect correction PRsPR Pull request, or other non-functional PRsPR Pull request (e.g. security remediations).
  • Production patch releases require the approval of one reviewer
  • Production patch releases shall be reported to the CRWG.

Summary of release approval requirements​

Type of releaseApproval requirementNotes
Major Release (6.0.0)2 reviewersScheduling via SWG; Include analysis of the changes from last major release as part of the approval
Minor Release (6.1.0)2 reviewersScheduling is up to the reviewers, but aim to keep to around every 4 weeks and no more than fortnightly
Patch Release (6.1.1)1 reviewerScheduling is up to the reviewer
Development Release (6.0.0-dev.13)1 reviewerScheduling is up to the reviewer