Release management (Draft)
This document describes the release management process for EHF Post-Award G3.
General
Information regarding releases are always published as announcements on anskaffelser.dev in addition to release notes in the updated specifications. Service providers are responsible for keeping up-to-date on upcoming changes, e.g. by subscribing to the RSS feed provided.
Publishing of releases are done on Tuesdays, Wednesdays or Thursdays, and swithing from one version to another happens at noon (12:00 PM) Central European Time (CET/CEST). Common holidays are avoided or results in additional time for migration and review periods of 4 weeks or less.
DFØ will make sure service providers are given minimum 3 months to align their software to foreseeable changes in specifications.
Major versions (X.0.0)
Major versions are typically used to introduce new specifications in the Norwegian market or to mirror major versions of specifications provided by OpenPeppol.
| Timeline | |
|---|---|
| Notification prior to release | 4 or 12 months* |
| Review period prior to release | 8 weeks |
| Release month | September |
| Migration period | 4 or 12 months* |
* New major versions without previous major versions are introduced with notification and migration periods at 4 months, major versions following a previous major version are introduced with notification and migration periods at 12 months.
To make sure releases of major versions are smooth, the following rules apply:
- Major versions requires changes in SMP.
- Receivers supporting the previous version when migration is initiated must support the previous version until migration is completed if they intend to support the new version.
Minor versions (x.Y.0)
Minor versions are typically used to introduce new functionality to existing specifications and to align towards specifications provided by OpenPeppol.
| Timeline | |
|---|---|
| Notification prior to release | 6 months |
| Review period prior to release | 4 weeks |
| Release months | May November |
| Migration period | 6 months |
To make sure releases of minor versions are smooth, the following rules apply:
- Minor versions requires changes in SMP.
- Receivers supporting the previous version when migration is initiated must support the previous version until migration is completed if they intend to support the new version.
Patch versions (x.y.Z)
Patch versions are typically used to update documentation, validation and codelists part of the specification.
| Timeline | |
|---|---|
| Notification prior to release | 4 weeks |
| Review period prior to release | 4 weeks |
| Release months | February May September November |
| Migration period | 2 weeks |
To make sure releases of patch versions are smooth, the following rules apply:
- Patch versions are not reflected in SMP.
- Updated validation rules are not to be used by receivers before migration period is completed.
- Validation rules expected to change severety (warning to error) are announced in release notes at least one release before change to severety.
- New codes in codelists may be used by senders after migration period.
Hotfix versions (x.y.Z)
Hotfix versions are patch versions with a shorter timeline from release to usage in the market. Release of hotfix is a last resort option when something is clearly wrong with the latest release. This option is typically not used, however when used will it contain fixes to only those issues triggering the need of such a release.
Timelines for hotfix versions are defined in the release notes.