# 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 Inventory_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) |
| `Inventory_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 Inventory_frontend && npm install && npx nuxi generate
```