This page will describe the basic process for managing feature inclusion within a release, and the associated versioning strategy.

Features

Features proposed for inclusion in a release may be categorized as follows:

• User driven
  • Users refers specifically to WMDA member registries (or their delegates) that currently use or intend to use the Match-Connect apis
  • During the early design and implementation phases of Match-Connect, features will be proposed by the Match-Connect Steering Committee and participating pilot registries
  • Following the pilot phase, all user driven features will be requested via the Match-Connect User Group RFC Process
• Implementation team driven
  • Implementation team refers to the technical staff of the WMDA and their associates that are directly involved in the implementation of the Match-Connect apis
  • The implementation team may need to include items in a release to resolve defects, improve underlying design, update dependencies / libraries and to keep the software in good, working order

Process

Whether user driven or implementation team driven, any proposed inclusions will be logged / summarized in the WMDA Share under the Match-Connect Release Management page as part of a release candidate package.  In the immediate term, the Match-Connect Steering Committee will assist with determination of impact and effort in order to assign features to a given release candidate.  Each candidate feature will be given a disposition (Approved, Rejected, moved to RFC).  Implementation actions (updating code, updating the semantics, updating swagger, etc) will be recorded on the release candidate page and tracked for completion.  

The implementation team will leverage Azure Dev Ops for more detailed tracking of their software development work.  The Match-Connect Product Owner will take responsibility for ensuring synchronization of feature inclusion into the detailed work items in Azure Dev Ops.

Feature Impact Categorizations

• Minor = cosmetic or wording only
• Moderate = api change
• Major = significant behavioral change

Example(s) of Candidate Features

The following snapshot is pulled from the MC v1.01 Release Candidate.

Versioning

The semantic versioning scheme will be utilized for Match-Connect releases going forward.  It can be summarized as follows:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes
2. MINOR version when you add functionality in a backward compatible manner
3. PATCH version when you make backward compatible bug fixes

Release candidates will be tagged according to this strategy both in the WMDA Share, Match-Connect Semantics and Azure Dev Ops.

Release Timing

Major changes must be coordinated with the community and should only be made on a periodic basis (e.g. once / year).  Minor changes and patches may occur at the discretion of the Match-Connect implementation team, with an aim towards continuous delivery.

Release Notes

Release notes shall be generated coincident with each release of Match-Connect.  Depending upon the audience, these notes may be generated from the release candidate page(s) in WMDA Share OR directly from Azure Dev Ops.