123 lines
3.2 KiB
Markdown
123 lines
3.2 KiB
Markdown
# Guide de Release
|
|
|
|
## C'est quoi une release ?
|
|
|
|
Une release c'est une **version officielle** de l'application. Chaque release a un numéro de version (ex: `1.8.1`) et est marquée par un **tag git**.
|
|
|
|
## Versioning (Semantic Versioning)
|
|
|
|
Le projet utilise le [Semantic Versioning](https://semver.org/) : `MAJOR.MINOR.PATCH`
|
|
|
|
| Type | Quand l'utiliser | Exemple |
|
|
|------|------------------|---------|
|
|
| **PATCH** | Correction de bug, pas de nouvelle fonctionnalité | `1.8.0` → `1.8.1` |
|
|
| **MINOR** | Nouvelle fonctionnalité, rétrocompatible | `1.8.1` → `1.9.0` |
|
|
| **MAJOR** | Changement majeur, potentiellement incompatible | `1.9.0` → `2.0.0` |
|
|
|
|
La version est centralisée dans le fichier `VERSION` à la racine du projet.
|
|
|
|
## Créer une release
|
|
|
|
### Prérequis
|
|
|
|
- Tous les changements doivent être commités (pas de fichiers modifiés non commités)
|
|
- Les tests doivent passer (`make test`)
|
|
- Être sur la branche à releaser (généralement `develop` ou `master`)
|
|
|
|
### Utilisation du script
|
|
|
|
```bash
|
|
# Afficher l'aide et la version actuelle
|
|
./scripts/release.sh
|
|
|
|
# Bump patch : 1.8.1 → 1.8.2
|
|
./scripts/release.sh patch
|
|
|
|
# Bump minor : 1.8.1 → 1.9.0
|
|
./scripts/release.sh minor
|
|
|
|
# Bump major : 1.8.1 → 2.0.0
|
|
./scripts/release.sh major
|
|
|
|
# Version spécifique
|
|
./scripts/release.sh 2.0.0
|
|
```
|
|
|
|
### Que fait le script ?
|
|
|
|
1. Vérifie qu'il n'y a pas de changements non commités
|
|
2. Vérifie/commit le submodule frontend si nécessaire
|
|
3. Met à jour le fichier `VERSION` avec le nouveau numéro
|
|
4. Met à jour `config/packages/api_platform.yaml` (version affichée dans l'API)
|
|
5. Crée un commit `chore(release) : vX.Y.Z`
|
|
6. Crée le tag git `vX.Y.Z`
|
|
7. Affiche les commandes pour pousser
|
|
|
|
### Pousser la release
|
|
|
|
Après avoir exécuté le script :
|
|
|
|
```bash
|
|
# Pousser le frontend d'abord (si modifié)
|
|
cd frontend && git push && git push --tags && cd ..
|
|
|
|
# Pousser le backend
|
|
git push && git push --tags
|
|
```
|
|
|
|
### Créer la release sur Gitea
|
|
|
|
1. Aller sur le dépôt Gitea
|
|
2. **Releases** > **New Release**
|
|
3. Sélectionner le tag `vX.Y.Z`
|
|
4. Titre : `vX.Y.Z` (ou avec un nom descriptif)
|
|
5. Description : résumé des changements (copier depuis CHANGELOG.md)
|
|
|
|
## Fichiers impactés par le versioning
|
|
|
|
| Fichier | Rôle |
|
|
|---------|------|
|
|
| `VERSION` | Source unique de vérité |
|
|
| `config/packages/api_platform.yaml` | Version affichée dans la doc API (Swagger) |
|
|
| `frontend/nuxt.config.ts` | Lit `VERSION` au build pour l'afficher dans le footer |
|
|
| Footer de l'app | Affiche `v{{ appVersion }}` |
|
|
|
|
## Notes de release
|
|
|
|
Template pour les notes de release (à copier dans Gitea) :
|
|
|
|
```markdown
|
|
## Nouveautés
|
|
- Feature A
|
|
- Feature B
|
|
|
|
## Corrections
|
|
- Fix du bug X
|
|
- Fix du bug Y
|
|
|
|
## Changements
|
|
- Refactoring de Z
|
|
- Mise à jour des dépendances
|
|
|
|
## Migration requise
|
|
\`\`\`bash
|
|
docker compose exec web php bin/console doctrine:migrations:migrate
|
|
\`\`\`
|
|
```
|
|
|
|
## Déploiement après une release
|
|
|
|
Voir [DEPLOY.md](DEPLOY.md) pour les instructions de mise à jour en production.
|
|
|
|
En résumé :
|
|
```bash
|
|
# Sur le serveur de production
|
|
cd /var/www/Inventory
|
|
git pull
|
|
git submodule update --init --recursive
|
|
composer install --no-dev --optimize-autoloader
|
|
php bin/console doctrine:migrations:migrate --no-interaction
|
|
php bin/console cache:clear --env=prod
|
|
cd frontend && npm install && npx nuxi generate
|
|
```
|