Stratégie de versioning CalVer

Pour assurer une traçabilité claire des évolutions et des mises en production, le projet adoptera une stratégie de versioning basée sur le calendrier, connue sous le nom de CalVer. Cette approche est préférée au Versionnement Sémantique (SemVer) car les versions du site refléteront directement la date de leur déploiement, ce qui est plus intuitif pour le suivi des livraisons fonctionnelles.

Format de Version CalVer

Le format de version retenu est YYYY.MM.MICRO.

• YYYY : Année sur quatre chiffres (ex: 2025).
• MM : Mois sur deux chiffres, avec zéro de remplissage (ex: 07 pour Juillet).
• MICRO : Numéro de déploiement séquentiel dans le mois, commençant à 0 (zéro). Ce numéro est incrémenté pour chaque nouvelle mise en production effectuée au cours du même mois. Exemples de versions :
• 2025.07.0 : Le premier déploiement réalisé en juillet 2025.
• 2025.07.1 : Un deuxième déploiement (hotfix ou ajout fonctionnel) réalisé plus tard en juillet 2025.
• 2025.08.0 : Le premier déploiement réalisé en août 2025. Ce format offre une lisibilité immédiate sur l'âge d'une version et la fréquence des déploiements.

## Application dans le Workflow Git

La stratégie de versioning CalVer s'intègre parfaitement avec le workflow GitFlow. L'action de "versionner" se matérialise par la création d'un tag Git.

1. Création d'une Branche de Release :

   • Lorsque les fonctionnalités prévues pour la prochaine mise en production sont terminées et mergées dans la branche »dev », une branche de « release » est créée.
   • Le nom de la branche de « release » anticipe la version cible.
   • Exemple : git checkout -b release/2025.09.0 dev

2. Finalisation de la Release :

   • La branche de release est l'endroit où se déroulent les derniers tests de non-régression, les ajustements mineurs et la mise à jour de la documentation (comme le CHANGELOG.md). Aucun nouveau développement (feature) n'est ajouté à cette branche.
   • Une fois la branche de « release » validée et prête pour la production, elle est mergée dans « master » et dans « dev ».

3. Taggage de la Version :

   • Le tag est appliqué sur le commit de merge dans la branche « master ». C'est cet acte qui fige une version dans l'histoire du projet.

   • La commande Git pour créer un tag annoté (recommandé) est :

     # S'assurer d'être sur la branche 'master' et à jour 
     git checkout master
     git pull
     
     # Créer le tag
     git tag -a "2025.09.0" -m "Mise en production de Septembre 2025 : refonte de la page d'accueil et ajout du recrutement v2"
     
     # Pousser le tag vers le dépôt distant
     git push origin 2025.09.0

4. Gestion des Hotfixes :

   • Si une correction urgente est nécessaire en production, une branche « hotfix » est créée à partir de « master ».
   • Une fois la correction terminée, la branche « hotfix » est mergée dans « master » ET dans « dev » pour s'assurer que la correction est reportée dans le flux de développement principal.
   • Un nouveau tag est créé sur « master », en incrémentant le numéro MICRO.
   • Exemple : Si la version en production est 2025.09.0, le hotfix sera taggé 2025.09.1.