LMS Contract Versioning
Summary
All nine Training integration contracts include the shared schema-version field; invoked producers use only version 1.
Audience
Engineering, integration, QA, architecture, security, product, and support reviewers.
Reference Content
The shared integration-event base supports a schema version. Every verified Training producer construction sets version 1. Notification reads version metadata and uses version 1 when that metadata is absent, but its Training resolver does not branch on or validate the version. The serialized contract retains its version, while the outbox model and shared publisher metadata builder do not provide a separate schema-version field or header.
No compatibility validator, alternate Training schema version, deprecation metadata, multi-version handler, migration strategy, or semantic-versioning rule was found. Contract change approval and compatibility governance therefore Require confirmation.
| Evidence | Finding |
|---|---|
| Version field | Implemented in the shared integration contract base |
| Distinct invoked-producer versions | 1 |
| Uninvoked expiry-contract producer version | Not observed |
| Consumer default | Version 1 when version metadata is absent |
| Compatibility and deprecation | Not implemented |
Source References
microservices/src/contracts/Events/IntegrationEvent.csmicroservices/src/contracts/Events/TrainingLifecycleEvents.csmicroservices/src/training-service/Infrastructure/TrainingDbContext.csmicroservices/src/notification-service/Messaging/NotificationEventConsumer.cs
Related Articles
See Also
Keywords
- Schema version
- Contract compatibility
- Version governance
Revision Information
- Status: Draft
- Last reviewed: 2026-07-17
- Review cycle: Quarterly