Capgo Semver Tester

Vérifier la compatibilité de la politique du canal avec la baseline native envoyée en version_build

Version native de référence

La version native envoyée à Capgo en tant que version_build, depuis la config ou les métadonnées natives de l'app.

Version distante

La version du bundle assignée au canal résolu.

Saisissez deux versions sémantiques pour voir la comparaison

Ce que signifie « Native Baseline Version »

La version de référence native est la version de l’application native envoyée à Capgo en version_build lorsque l’appareil demande un bundle au serveur de mise à jour. Dans une application Capacitor, cette valeur peut provenir de CapacitorUpdater.version dans capacitor.config.*. Si ce paramètre n’est pas présent, le plugin utilise la version native de l’application iOS ou Android. Ne supposez pas qu’il s’agit de votre package.json version, sauf si votre build copie cette valeur dans la config ou les métadonnées natives.

Capgo utilise toujours version_name pour savoir quel bundle téléchargé est actuellement installé. Les politiques semver de canal telles que major, minor, et patch comparent le bundle distant avec version_build.

Configuration Capacitor

Définissez CapacitorUpdater.version quand vous voulez qu'une version explicite soit envoyée par l'app.

Pro : facile de garder la même version sur les builds iOS et Android.

Con : une config obsolète peut indiquer la mauvaise version si vous oubliez de la mettre à jour avant une release native.

Version de l'app native

Utilisez la version de la plateforme, par exemple iOS CFBundleShortVersionString ou Android versionName.

Pro : correspond au binaire installé par les utilisateurs via TestFlight, l'App Store, le Play Store ou vos tests internes.

Con : le modifier nécessite un build natif et peut varier selon la plateforme si les paramètres de release divergent.

Ciblage du bundle

Comparez-l’aux versions de bundle distantes, aux règles semver du canal ou aux contraintes d'upload de métadonnées telles que --min-update-version. Le canal doit utiliser --disable-auto-update metadata.

Pro : empêche l'envoi de JavaScript nécessitant un code natif plus récent vers d'anciens binaires d'application.

Con : des règles trop strictes peuvent bloquer des mises à jour valides jusqu'à ce que le canal ou les métadonnées du bundle soient ajustés.

Pour ce testeur, saisissez la référence native envoyée par l'appareil comme version_build, puis comparez-l’à la version du bundle distant que vous voulez que Capgo livre.

Pourquoi Capgo utilise le Semantic Versioning

Versionnage sémantique est le standard de versionnage le plus largement adopté dans le développement logiciel. En utilisant semver, Capgo garantit la compatibilité et la sécurité lors de la livraison de live updates à vos applications Capacitor.

Le standard semver permet à Capgo de comprendre exactement quels changements sont inclus dans chaque mise à jour :

Mises à jour de correctif (1.0.0 → 1.0.1) : Corrections de bugs, sûres à appliquer automatiquement
Mises à jour mineures (1.0.0 → 1.1.0) : Nouvelles fonctionnalités, rétrocompatibles
Mises à jour majeures (1.0.0 → 2.0.0) : Changements cassants, nécessitent une release sur le store natif

Cela empêche Capgo d’envoyer une mise à jour incompatible à votre application native code, protégeant vos utilisateurs des plantages et garantissant la stabilité de votre application.

Stratégies Semver flexibles : au-delà de la versionnage de base

Bien que semver soit strict quant à son format de base, vous pouvez l’étendre aux besoins de votre équipe en utilisant identifiants de pré-release et métadonnées de build:

🏷️ Métadonnées de build (+) - la couche « cosmétique »

1.2.0+20240315.142530

Horodatage pour le suivi du déploiement

1.2.0+ui.refresh.dark-mode

Description de la mise à jour UI pour l'équipe design

1.2.0+build.4729.commit.a1b2c3d

Numéro de build CI/CD et commit git

Important : Les métadonnées de build sont ignorées dans la précédence des versions - 1.2.0+anything égal à 1.2.0 pour la logique de mise à jour de Capgo.

🔧 Identifiants de pré-release (-) - Canaux de développement

1.3.0-beta.1

Canal de test bêta

1.3.0-hotfix.payment

Branche de correctif urgent

1.3.0-feature.newapi

Test de branche fonctionnalité

Note : Les versions de pré-release ont une priorité inférieure - 1.3.0-beta.1 < 1.3.0

🎯 Approche hybride - Le meilleur des deux mondes

1.3.0-rc.1+ui.redesign.20240315

Candidat de release avec métadonnées UI et horodatage

Cas d'usage concrets de Semver et stratégies d'équipe

🚀 Startup / développement rapide

0.1.0 - Première release MVP

0.2.0-beta.1 - Test de nouvelles fonctionnalités

0.2.0+ui.v2 - Métadonnées de refonte UI

1.0.0 - Prêt pour la production

Utilisez 0.x.x pour le développement pré-1.0, et les métadonnées pour le suivi du design

🏢 Entreprise / secteur régulé

2.1.0 → Release trimestrielle

2.1.1+sec.patch.cve2024 → Patch de sécurité avec suivi

2.2.0-rc.1+audit.ready → Release candidate pré-audit

Semver strict avec métadonnées de conformité

🎮 Gaming / Apps créatives

1.0.0+season.winter.2024 → Contenu saisonnier

1.1.0+event.halloween → Fonctionnalités événementielles

1.2.0+assets.hd.remaster → Mises à jour d'assets

Métadonnées créatives pour le suivi du contenu

⚡ Stratégie de hotfix

1.2.0 → Production actuelle

1.2.1-hotfix.payment → Correction de bug critique

1.2.1+urgent.20240315.1430 → Publiée avec timestamp

Pré-release pour les tests, métadonnées de suivi du déploiement

🌍 Stratégie multiplateforme

1.3.0+ios.optimized → Optimisations spécifiques à iOS

1.3.0+android.material3 → Mises à jour du design Android

1.3.0+web.pwa.ready → Capacités PWA

Même version, métadonnées spécifiques à la plateforme

🔄 Intégration CI/CD

1.4.0-alpha.1+build.123 → Pré-release automatisée

1.4.0+deploy.staging.456 → Déploiement en staging

1.4.0+prod.final.789 → Déploiement en production

Versionnage automatisé avec métadonnées de déploiement

💡 Conseils pro :

Utilisez les métadonnées de build (+) pour le suivi, les horodatages ou les infos cosmétiques sans impact sur la compatibilité
Utilisez les identifiants de préversion (-) pour les canaux de développement nécessitant une priorité de mise à jour différente
Combinez les deux pour une flexibilité maximale : 1.2.0-beta.1+ui.dark.theme.20240315
Rappel : Capgo respecte les règles de priorité semver, planifiez donc votre stratégie de canaux en conséquence

Important : Capgo utilise un versionnage sémantique strict

Contrairement à l’implémentation semver de npm, Capgo respecte strictement la spécification officielle SemVer. Le node-semver de npm présente des écarts connus par rapport à la spec, susceptibles de provoquer un comportement inattendu.

Par exemple, npm traite les versions comme 1.0.0-alpha.1 différemment de ce que la spécification exige. Consultez notre problème signalé et correctif tenté qui n'a jamais été fusionné.

Versions sémantiques valides

1.0.0 ✓ Release standard

2.1.3-alpha ✓ Pré-release

1.0.0-beta.1 ✓ Pré-release avec numéro

1.0.0+build.1 ✓ Métadonnées de build

1.0.0-rc.1+build.1 ✓ Version complète

Versions sémantiques invalides

v1.0.0 ✗ Le « v » initial n'est pas autorisé

1.0 ✗ Version patch manquante

1.0.0.0 ✗ Trop de segments de version

1.0.0- ✗ Pré-release vide

1.0.0+ ✗ Métadonnées de build vides

Capgo Comportement de mise à jour

✓ La stratégie Minor autorise les changements de patch dans la même ligne major.minor, par exemple 1.0.0 -> 1.0.1

✓ La stratégie Patch bloque 1.0.0 -> 1.0.1. Elle n'autorise que les changements de suffixe comme 1.0.0-beta.1 -> 1.0.0-beta.2.

✗ La stratégie Major bloque les bundles ayant une version major supérieure à la version native de référence, par exemple 1.0.0 -> 2.0.0

⚠ La protection contre le downgrade utilise la priorité semver complète, donc la version stable 1.0.0 est plus récente que 1.0.0-beta.2

Cet outil suit la spécification officielle Spécification du versionnage sémantique contrairement à l'implémentation de npm.