Release

• 1: Release process
• 2: Publish a new release

1 - Release process

OSRD has three versions: development (dev), staging, and release.

The development version is the most recent and unstable version of the application, containing the latest features and bug fixes in active development.

Usual process

Staging versions are created every Thursday at 12pm by tagging the current development state.

If a staging version passes validation testing, it is promoted to become the latest release version. This ensures that only stable, tested code makes it into production releases.

The release process follows this workflow:

1. Ongoing development in the dev branch
2. Weekly staging tags on Thursdays at 12pm
3. Validation testing of staging version
4. Promotion of validated staging builds to release status

    Development         Staging                   Release
    (unstable)         (testing)                 (stable)

    [Dev Branch]                                    |
         |                                          |
         |--->     Thursday 12pm                    |
         |         [Staging Tag]                    |
         |                |                         |
         |            Validation                    |
         |             Testing                      |
         |                |                         |
         |                o---> If Passes -->  [New Release]
         |                       Tests              |
    [Continue Dev]                                  |
         |                                          |
         V                                          V

Stabilization and innovation iteration

Every 11 weeks, an iteration (2 weeks) is dedicated to stabilization and innovation.

The goal is to ensure that a stable version is released by this term (focus on bug detection and correction).

The work process during this period is as follows:

• The dev branch follows its usual process (to avoid blocking work or creating additional conflicts).
• A special focus is put on bugfix, through the following process:
  1. A fix PR is opened and merged on the dev branch.
  2. Then a new PR is opened to backport the fix to the staging branch.

A bug issue therefore requires 2 PRs to be closed. This process is maintained for 2 weeks (even if the validation tests are correct by the first week).

2 - Publish a new release

All OSRD releases are accessible here

The process for creating a new release is as follows:

1. We always release on a tested version of the application (staging branch)
   • git switch staging && git pull
2. Create a git annotated tag
   • We are using the semantic versioning
   • git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version)
   • git push --tags
3. Create a github release
   • Draft a new github release here
   • Select the created tag
   • Generate the releases notes
   • Rename the release like so: “Version x.y.z”
   • Check the “Set as a pre-release” box
   • Apply the changelog format
   • Then you can publish the release or save the draft if you want to come back later
4. A github action should be triggered automatically.
5. Post the link of the created release on matrix. Suggest that the developers review the release.

Changelog format

1. Use the following structure:

## What's Changed

### Features :tada:


### Code refactoring :recycle:


### Bug fixes :bug:


## New Contributors

<!-- Copy from the generated release notes -->
...

<!-- Copy from the generated release notes -->
**Full Changelog**: ...

2. Partition the different pull requests
3. Merge or group PR when it make sense. Examples:
   • Bump of dependencies PR (merge)
   • Multi part PR (merge)
   • One big feature implemented by multiple PR (group)
4. Reword PR title. It should be comprehensible to an external collaborator