Publication

• 1: Processus de publication
• 2: Publier une nouvelle version

1 - Processus de publication

OSRD possède trois versions : développement (dev), staging et publication.

La version de développement est la version la plus récente et la plus instable de l’application, contenant les dernières fonctionnalités et corrections de bugs en cours de développement.

Les versions staging sont créées tous les jeudis à 12h en taguant l’état actuel du développement.

Si une version staging passe les tests de validation, elle est promue pour devenir la dernière version publication. Cela garantit que seul du code stable et testé est intégré dans les versions de production.

Le processus de publication suit ce workflow :

1. Développement continu dans la branche dev
2. Tags de staging hebdomadaires les jeudis à 12h
3. Tests de validation de la version staging
4. Promotion des builds staging validés au statut de publication

    Développement      Staging                publication
    (instable)         (test)                   (stable)

    [Branche Dev]                                  |
         |                                         |
         |--->     Jeudi 12h                       |
         |         [Tag Staging]                   |
         |                |                        |
         |            Validation                   |
         |              Tests                      |
         |                |                        |
         |                o---> Si Passage -->  Nouvelle
         |                        Tests        publication
    [Suite Dev]                                    |
         |                                         |
         V                                         V

2 - Publier une nouvelle version

Toutes les versions d’OSRD sont accessibles ici

Le processus de création d’une nouvelle version est le suivant :

1. Nous publions toujours sur une version testée de l’application (branche staging)
   • git switch staging && git pull
2. Créer un tag git annoté
   • Nous utilisons le versionnement sémantique
   • git tag -a vx.y.z avec le message Release x.y.z (la plupart du temps, utilisez la dernière version et incrémentez la version patch)
   • git push --tags
3. Créer une release GitHub
   • Créer une nouvelle release GitHub ici
   • Sélectionner le tag créé
   • Générer les notes de version
   • Renommer la release ainsi : “Version x.y.z”
   • Cocher la case “Set as a pre-release”
   • Appliquer le format du changelog
   • Vous pouvez ensuite publier la release ou sauvegarder le brouillon si vous souhaitez y revenir plus tard
4. Une action GitHub devrait être déclenchée automatiquement.
5. Poster le lien de la release créée sur Matrix. Suggérer aux développeurs de revoir la release.

Format du changelog

1. Utiliser la structure suivante :

## 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. Répartir les différentes pull requests
3. Fusionner ou regrouper les PR quand cela a du sens. Exemples :
   • PR de mise à jour des dépendances (fusionner)
   • PR en plusieurs parties (fusionner)
   • Une grande fonctionnalité implémentée par plusieurs PR (regrouper)
4. Reformuler les titres des PR. Ils doivent être compréhensibles pour un collaborateur externe