Change Management for the BoB Standard
The BoB Change Management Process defines how the BoB standard is governed, maintained, and evolved over time. It provides a structured and transparent framework for proposing, evaluating, approving, and implementing changes, ensuring long-term stability, interoperability, and predictability for all organisations using the BoB standard.
The process applies to all parts of the BoB standard, including BoB APIs, the Mobile Ticket Specification (MTS), schemas, and related documentation.
The process is based on the following principles:
Openness – any eligible stakeholder may propose changes to the BoB standard.
Transparency – changes, reviews, and decisions are documented and communicated.
Impact awareness – technical, organisational, and business consequences are considered.
Formal governance – decision authority and mandates are clearly defined.
Governance and Roles
The BoB Change Management Process is governed through clearly defined roles and mandates.
A Change Request (CR) may be initiated by any stakeholder that has implemented, or plans to implement, the BoB standard, as well as by Samtrafiken. The initiator is responsible for preparing the Change Request and engaging in early dialogue with affected stakeholders.
Samtrafiken administers and coordinates the Change Management Process, including validation of Change Requests, coordination of reviews, and communication throughout the process. Samtrafiken is also authorised to implement Patch changes, while ensuring transparency towards stakeholders.
Each stakeholder appoints a BoB contact person, who acts as the formal interface in reviews and decision-making.
Final decisions on Major and Minor changes are taken by the Change Acceptance Board (CAB). Participation in the CAB is limited to organisations that finance the administration and governance of the BoB standard, typically through a Samtrafiken Partner Agreement (SPA). CAB decisions are made by consensus
Proposing a Change
A change to the BoB standard is initiated through a formal Change Request (CR). The Change Request is the primary input to the Change Management Process.
Eligibility
A Change Request may be submitted by:
Any stakeholder that has implemented, or plans to implement, the BoB standard
Samtrafiken
To contribute technically via Bitbucket, see BoB Participant Contribution →
Types of Changes and Releases
All changes to the BoB standard are classified according to their impact and compatibility. This classification determines both versioning and governance.
Major Changes
Major changes introduce non-backwards-compatible modifications to the BoB standard and require adaptations by implementing organisations.
Major changes follow the full Change Management Process and must be approved by the Change Acceptance Board (CAB). Decisions include the new version number and timelines for when older versions will no longer be supported.
Minor Changes
Minor changes introduce backwards-compatible enhancements or extensions. Existing implementations can continue to operate unchanged.
Minor changes also require CAB approval to ensure alignment and avoid fragmentation.
Patch Changes
Patch changes consist of backwards-compatible corrections or clarifications that do not introduce new functionality or affect interoperability.
For patch changes, Samtrafiken is authorised to implement and release the update without a CAB decision. Stakeholders are informed to maintain transparency.
For a complete overview of released major profiles and their included versions, see BoB major release profiles →
Version Numbering
Within the BoB standard, each API, the Mobile Ticket Specification (MTS), and each schema is versioned independently.
Version numbers follow the semantic versioning format:
MAJOR.MINOR.PATCH
This means that changes to one API, schema, or specification do not automatically affect the version of others.
MAJOR versions indicate non-backwards-compatible changes.
MINOR versions indicate backwards-compatible enhancements or extensions.
PATCH versions indicate backwards-compatible corrections or clarifications.
Version numbers clearly communicate the impact of a change and support predictable implementation planning.
Change Flow
The Change Management Process follows a defined end-to-end flow to ensure predictability and transparency.
Initiation and early dialogue with affected stakeholders
Submission of a Change Request
Evaluation and review for Major and Minor changes
Decision by the CAB (GO / NO GO)
Update definitions and documentation
Communication and follow-up
Patch changes may be implemented by Samtrafiken without a CAB decision, while keeping stakeholders informed.
To follow the status of registered and ongoing BoB issues, see BoB issues - status filter list →
Change Request Content and Requirements
After the initial early dialogue in BoB Tech forum the initiator creates and submits a formal Change request. Each Change Request must be documented using the BoB Change Request template and include information appropriate to the type of change.
General Information
Type of change (Major, Minor, or Patch)
Date
Requested by (organisation and contact details)
Description of the Change
Current situation
Desired situation and purpose
Proposed solution
Scope and Impact
Affected specifications and APIs (including versions)
Other affected stakeholders
Consequences (technical, organisational, and business)
Planning and Risk
Time schedule
Risk analysis
Before formal submission, the initiator is expected to engage in dialogue with affected stakeholders to clarify impacts and support an efficient review.