Livraison de version

Workflow de publication systématique pour RTK : vérification de la compilation, changement de version, mise à jour du changelog, étiquette git et push pour déclencher la CI/CD.

Quand l'utiliser

Invocation manuelle : Quand prêt à publier une nouvelle version
Après la finalisation d'une fonctionnalité : Avant le tagging et la publication
Avant le changement de version : Pour automatiser la checklist de publication

Checklist de pré-publication (vérification automatisée)

Avant d'exécuter /ship, vérifiez :

1. Les vérifications de qualité passent

cargo fmt --all --check    # Code formaté
cargo clippy --all-targets # Zéro avertissements
cargo test --all           # Tous les tests passent

2. Les benchmarks de performance passent

hyperfine 'target/release/rtk git status' --warmup 3
# Devrait afficher <10ms mean time

/usr/bin/time -l target/release/rtk git status
# Devrait afficher <5MB maximum resident set size

3. Les tests d'intégration passent

cargo install --path . --force  # Installer localement
cargo test --ignored            # Exécuter les tests d'intégration

4. État de Git propre

git status  # Devrait afficher "nothing to commit, working tree clean"

Workflow de publication

Étape 1 : Déterminer le changement de version

Versionnage sémantique (MAJOR.MINOR.PATCH) :

MAJOR (v1.0.0) : Changements cassants (rare pour RTK)
MINOR (v0.X.0) : Nouvelles fonctionnalités, nouveaux filtres, nouvelles commandes
PATCH (v0.0.X) : Corrections de bugs, améliorations de performance

Exemples :

Nouveau filtre ajouté (rtk pytest) → changement MINOR (v0.16.0 → v0.17.0)
Correction de bug dans le filtre git log → changement PATCH (v0.16.0 → v0.16.1)
Changement cassant d'argument CLI → changement MAJOR (v0.16.0 → v1.0.0)

Étape 2 : Mettre à jour la version

Fichiers à mettre à jour :

Cargo.toml (ligne 3) : version = "X.Y.Z"
README.md (si la version est mentionnée)

Note : CHANGELOG.md est auto-généré par release-please à partir des messages de commit conventionnels — ne pas éditer manuellement.

Exemple :

# Cargo.toml (avant)
[package]
name = "rtk"
version = "0.16.0"  # Version actuelle

# Cargo.toml (après - changement MINOR)
[package]
name = "rtk"
version = "0.17.0"  # Nouvelle version

Template CHANGELOG.md :

## [0.17.0] - 2026-02-15

### Added
- Commande `rtk pytest` pour le filtrage de tests Python (réduction de 90% des tokens)
- Support pour l'analyse des sorties JSON `pytest`
- Intégration avec auto-détection du gestionnaire de paquets `uv`

### Fixed
- Échappement de shell pour PowerShell sur Windows
- Fuite mémoire dans le cache de patterns regex

### Changed
- Filtre `cargo test` mis à jour pour afficher les noms de tests en cas d'échec

Étape 3 : Compiler et vérifier

# Compilation propre
cargo clean
cargo build --release

# Vérifier le binaire
target/release/rtk --version
# Devrait afficher la nouvelle version

# Exécuter les vérifications de qualité complètes
cargo fmt --all --check
cargo clippy --all-targets
cargo test --all

# Benchmarker la performance
hyperfine 'target/release/rtk git status' --warmup 3
# Devrait toujours être <10ms

Étape 4 : Commiter le changement de version

# Préparer les fichiers de version
git add Cargo.toml Cargo.lock README.md

# Commiter avec l'étiquette de version
git commit -m "chore(release): bump version to v0.17.0

- Updated Cargo.toml version
- Verified all quality checks pass
- Benchmarked performance (<10ms startup)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"

Étape 5 : Créer l'étiquette Git

# Créer une étiquette annotée avec un extrait du changelog
git tag -a v0.17.0 -m "Release v0.17.0

Added:
- rtk pytest command (90% token reduction)
- Support for uv package manager

Fixed:
- Shell escaping for PowerShell
- Memory leak in regex caching

Performance: <10ms startup, <5MB memory"

Étape 6 : Push vers le remote

# Push le commit et les étiquettes
git push origin main
git push origin v0.17.0

# Déclencher le workflow de publication GitHub Actions
# (La CI/CD compilera les binaires, créera une version GitHub, publiera sur crates.io si configuré)

Vérification post-publication

Après le push, vérifiez :

1. La CI/CD GitHub Actions passe

# Vérifier le statut du workflow GitHub Actions
gh run list --limit 1

# Surveiller la dernière exécution
gh run watch

2. La version GitHub créée

# Vérifier si la version est créée
gh release view v0.17.0

# Devrait afficher :
# - Notes de publication du tag git
# - Binaires attachés (macOS, Linux x86_64/ARM64, Windows)
# - Checksums pour vérification

3. Vérification de l'installation

# Tester l'installation depuis la version
curl -sSL https://github.com/rtk-ai/rtk/releases/download/v0.17.0/rtk-macos-latest -o rtk
chmod +x rtk
./rtk --version
# Devrait afficher v0.17.0

Plan de restauration

Si la version a des problèmes critiques :

Option 1 : Publication de correction (préférée)

# Corriger le problème dans une nouvelle branche
git checkout -b hotfix/v0.17.1
# Appliquer la correction
cargo test --all
git commit -m "fix: critical issue in pytest filter"

# Publier v0.17.1 (changement PATCH)
# Suivre le workflow de publication ci-dessus

Option 2 : Marquer comme rejetée (crates.io uniquement)

# Marquer la version comme rejetée sur crates.io
cargo yank --vers 0.17.0

# Les utilisateurs ne peuvent pas télécharger la version rejetée, mais les installations existantes fonctionnent

Option 3 : Restaurer l'étiquette (dernier recours)

# Supprimer l'étiquette localement
git tag -d v0.17.0

# Supprimer l'étiquette sur le remote
git push origin :refs/tags/v0.17.0

# Supprimer la version GitHub
gh release delete v0.17.0 --yes

# Restaurer le commit
git revert HEAD
git push origin main

Script de publication automatisée (optionnel)

Enregistrer en tant que scripts/ship.sh :

#!/bin/bash
set -euo pipefail

# Analyser l'argument de version
if [ $# -ne 1 ]; then
    echo "Usage: $0 <version>"
    echo "Example: $0 0.17.0"
    exit 1
fi

NEW_VERSION=$1

echo "🚀 Starting release workflow for v$NEW_VERSION"

# 1. Quality checks
echo "📦 Running quality checks..."
cargo fmt --all --check
cargo clippy --all-targets
cargo test --all

# 2. Update version
echo "🔢 Updating version to $NEW_VERSION..."
sed -i '' "s/^version = .*/version = \"$NEW_VERSION\"/" Cargo.toml

# 3. Build
echo "🔨 Building release binary..."
cargo build --release

# 4. Verify version
echo "✅ Verifying version..."
target/release/rtk --version | grep "$NEW_VERSION"

# 5. Commit
echo "💾 Committing version bump..."
git add Cargo.toml Cargo.lock
git commit -m "chore(release): bump version to v$NEW_VERSION

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"

# 6. Tag
echo "🏷️  Creating git tag..."
git tag -a "v$NEW_VERSION" -m "Release v$NEW_VERSION"

# 7. Push
echo "🚢 Pushing to remote..."
git push origin main
git push origin "v$NEW_VERSION"

echo "✅ Release v$NEW_VERSION shipped!"
echo "Monitor CI/CD: gh run watch"

Utilisation :

chmod +x scripts/ship.sh
./scripts/ship.sh 0.17.0

Fréquence de publication

Cadence recommandée :

Publications PATCH : Au besoin pour les bugs critiques (délai de 24h)
Publications MINOR : Chaque semaine ou deux semaines pour les nouvelles fonctionnalités
Publications MAJOR : Trimestriellement ou quand des changements cassants sont nécessaires

Référence d'historique de version

Vérifier l'historique de version :

git tag -l "v*"  # Lister tous les tags de version
git log --oneline --tags  # Afficher les commits avec tags

Exemple de sortie :

v0.17.0 (HEAD -> main, tag: v0.17.0, origin/main)
v0.16.0
v0.15.1
v0.15.0

Problèmes courants

Problème : La CI/CD échoue après le push du tag

Symptôme : Le workflow GitHub Actions échoue lors de la compilation de publication

Solution :

# Corriger le problème localement
git checkout main
# Appliquer la correction
cargo test --all
git commit -m "fix: CI/CD build issue"
git push origin main

# Supprimer l'ancien tag
git tag -d v0.17.0
git push origin :refs/tags/v0.17.0

# Créer un nouveau tag
git tag -a v0.17.0 -m "Release v0.17.0 (rebuild)"
git push origin v0.17.0

Problème : Incompatibilité de version

Symptôme : rtk --version affiche l'ancienne version après le changement