docs: Ajout du guide de workflow de développement CLAUDE.md
- Documentation du processus de finalisation des modifications - Workflow en 4 étapes : changelog → version → commit → build - Convention de versioning SemVer - Guidelines pour les messages de commit - Instructions pour le build multi-plateforme
This commit is contained in:
122
CLAUDE.md
Normal file
122
CLAUDE.md
Normal file
@@ -0,0 +1,122 @@
|
||||
# Instructions pour Claude - Workflow de développement
|
||||
|
||||
## 📋 Processus de finalisation des modifications
|
||||
|
||||
Lorsqu'une fonctionnalité ou correction est terminée, suivre systématiquement ce workflow :
|
||||
|
||||
### 1. 📝 Mettre à jour le changelog
|
||||
|
||||
**Fichier** : `docs/changelog.md`
|
||||
|
||||
- Ajouter une nouvelle section avec le numéro de version suivant
|
||||
- Format de date : `AAAA-MM-JJ`
|
||||
- Structurer les changements par catégories :
|
||||
- **Ajouté** : Nouvelles fonctionnalités
|
||||
- **Modifié** : Changements aux fonctionnalités existantes
|
||||
- **Corrigé** : Corrections de bugs
|
||||
- **Supprimé** : Fonctionnalités retirées
|
||||
- **Technique** : Détails d'implémentation
|
||||
- **Documentation** : Mises à jour de docs
|
||||
|
||||
Exemple :
|
||||
```markdown
|
||||
## [1.2.16] - 2025-09-05
|
||||
|
||||
### Ajouté
|
||||
- **Titre de la fonctionnalité** : Description courte
|
||||
- Détail spécifique avec bullet points
|
||||
- Autre détail important
|
||||
```
|
||||
|
||||
### 2. 🔢 Bump de version
|
||||
|
||||
**Fichier** : `package.json`
|
||||
|
||||
Mettre à jour le champ `"version"` selon la convention SemVer :
|
||||
|
||||
- **PATCH** (x.x.+1) : Corrections de bugs, petits ajustements
|
||||
- **MINOR** (x.+1.0) : Nouvelles fonctionnalités compatibles
|
||||
- **MAJOR** (+1.0.0) : Changements majeurs non rétrocompatibles
|
||||
|
||||
**Méthodes** :
|
||||
|
||||
Option 1 - Manuellement :
|
||||
```json
|
||||
"version": "1.2.16",
|
||||
```
|
||||
|
||||
Option 2 - Avec npm (si le repo est clean) :
|
||||
```bash
|
||||
npm version patch # ou minor/major
|
||||
npm version 1.2.16 # version spécifique
|
||||
```
|
||||
|
||||
### 3. 📦 Commit Git
|
||||
|
||||
Faire un commit structuré avec tous les changements :
|
||||
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "type: Description courte
|
||||
|
||||
- Détail important 1
|
||||
- Détail important 2
|
||||
- Bump version X.X.X"
|
||||
```
|
||||
|
||||
**Types de commit** :
|
||||
- `feat:` Nouvelle fonctionnalité
|
||||
- `fix:` Correction de bug
|
||||
- `refactor:` Refactoring de code
|
||||
- `docs:` Documentation
|
||||
- `style:` Formatage, style
|
||||
- `chore:` Maintenance
|
||||
|
||||
### 4. 🏗️ Build (optionnel)
|
||||
|
||||
Si nécessaire, créer les builds de distribution :
|
||||
|
||||
```bash
|
||||
# Linux
|
||||
npx electron-builder --linux --x64
|
||||
|
||||
# Windows
|
||||
npx electron-builder --win
|
||||
|
||||
# macOS
|
||||
npx electron-builder --mac
|
||||
```
|
||||
|
||||
## 📌 Exemple complet
|
||||
|
||||
```bash
|
||||
# 1. Éditer docs/changelog.md avec la nouvelle version
|
||||
# 2. Éditer package.json pour bumper la version
|
||||
# 3. Commit
|
||||
git add -A
|
||||
git commit -m "feat: Ajout système de logging SignalR et corrections UI
|
||||
|
||||
- Système de logging complet dans ~/.simpleconnect-ng/signalr.log
|
||||
- Remplacement des emojis par icônes SVG
|
||||
- Suppression du menu Electron
|
||||
- Bump version 1.2.16"
|
||||
|
||||
# 4. Build si nécessaire
|
||||
npx electron-builder --linux --x64
|
||||
```
|
||||
|
||||
## ⚠️ Points d'attention
|
||||
|
||||
1. **Toujours** mettre à jour le changelog AVANT de bumper la version
|
||||
2. **Vérifier** que la version dans le changelog correspond à celle du package.json
|
||||
3. **Inclure** "Bump version X.X.X" dans le message de commit
|
||||
4. **Ne pas** référencer Claude ou Anthropic dans les commits
|
||||
5. **Utiliser** la date du jour (vérifier avec `date` si nécessaire)
|
||||
|
||||
## 🎯 Objectif
|
||||
|
||||
Ce workflow garantit :
|
||||
- Une traçabilité complète des changements
|
||||
- Des versions cohérentes entre documentation et code
|
||||
- Un historique Git propre et informatif
|
||||
- Une facilité de génération des releases
|
||||
Reference in New Issue
Block a user