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.

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

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