Capgo Testeur de Semver

Vérifiez la compatibilité de la version semantique pour les mises à jour de votre application Capacitor

Version locale

La version que votre application installée signale à Capgo, à partir de la configuration ou des métadonnées natives de l'application.

Version distante

Entrez deux versions semantiques pour voir la comparaison

Ce que signifie "Version locale"

La version locale est la version déjà présente sur le dispositif lorsque celui-ci demande à l'update server un bundle. 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 se réfère à la version native de l'application iOS ou Android. N'assumez pas qu'il s'agit de votre package.json version à moins que votre build ne copie cette valeur dans la config ou les métadonnées natives.

Capacitor config

Définir CapacitorUpdater.version lorsque vous souhaitez une version explicite envoyée par l'application.

Avantages : facile à conserver identique pour les builds iOS et Android.

Inconvénients : une config obsolète peut signaler la mauvaise version si vous oubliez de la mettre à jour avant une mise en production native.

Version de l'application native

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

Avantages : correspond à la version binaire que les utilisateurs ont installée à partir de TestFlight, App Store, Play Store ou de tests internes.

Contrairement à cela Modifier cela nécessite une compilation native et peut différer par plateforme si les paramètres de publication dérivent.

Ciblage de la mise en boîte

Comparez-le avec les versions de mise en boîte distantes, les règles de semver de canal ou les contraintes d'upload telles que --native-version.

Pro Empêche d'envoyer du JavaScript qui nécessite une version native plus récente de code pour les anciens binaires d'applications.

Contrairement à cela Les règles qui sont trop strictes peuvent bloquer les mises à jour valides jusqu'à ce que le canal ou les métadonnées de la mise en boîte soient ajustés.

Pour ce testeur, entrez la version que le dispositif rapporterait comme locale, puis comparez-la avec la version de mise en boîte distante que vous souhaitez Capgo livrer.

Pourquoi Capgo utilise la versionnement sémantique

Versionnement sémantique est la norme de versionnement la plus largement adoptée dans le développement logiciel. En utilisant semver, Capgo assure la compatibilité et la sécurité lors de la livraison d'actualisations en direct vers vos Capacitor applications.

La norme semver permet à Capgo de comprendre exactement quelles modifications sont incluses dans chaque mise à jour :

Mises à jour de patch (1.0.0 → 1.0.1) : Corrections de bogues, sécuritaire à appliquer automatiquement
Mises à jour mineures (1.0.0 → 1.1.0) : Nouvelles fonctionnalités, compatibles avec le mode arrière
Mises à jour majeures (1.0.0 → 2.0.0) : Changements de rupture, nécessitent une mise à jour native de l'app store

Cela empêche Capgo de jamais envoyer une mise à jour incompatible à votre application native code, protégeant vos utilisateurs des plantages et garantissant que votre application reste stable.

Stratégies de semver flexibles : au-delà de la versionnement de base

Même si semver est strict sur sa forme de base, vous pouvez l'étendre pour répondre aux besoins de votre équipe en utilisant identificateurs de pré-version et informations de build:

🏷️ Informations de build (+) - La couche "Cosmétique"

1.2.0+20240315.142530

Heure de déploiement pour le suivi

1.2.0+ui.refresh.dark-mode

Description de mise à jour de l'interface pour l'équipe de design

1.2.0+build.4729.commit.a1b2c3d

Numéro de build CI/CD et commit Git

Important : Les informations de build sont ignorées dans la priorité de version - 1.2.0+anything équivaut à 1.2.0 pour la logique de mise à jour de Capgo.

Identificateurs de pré-version (-) - Canaux de développement

1.3.0-beta.1

Chaîne de test de version bêta

1.3.0-hotfix.payment

Branchement de correction urgente

1.3.0-feature.newapi

Chaîne de test de branche de fonctionnalité

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

Approche hybride - Meilleur des deux mondes

1.3.0-rc.1+ui.redesign.20240315

Candidate de version avec métadonnées d'interface utilisateur et horodatage

Utilisation et stratégies de l'équipe pour Semver dans le monde réel

🚀 Développement rapide / Startup

0.1.0 - Première mise en production de MVP

0.2.0-beta.1 - Test de nouvelle fonctionnalité

0.2.0+ui.v2 - Mise à jour de la métadonnée de la conception de l'interface utilisateur

1.0.0 - Prêt pour la production

Utilisez 0.x.x pour le développement pré-1.0, métadonnée pour le suivi de la conception

🏢 Entreprise / Réglementée

2.1.0 → Sortie trimestrielle

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

2.2.0-rc.1+audit.ready → Candidat à l'examen préalable

Semver strict avec métadonnée de conformité

Jeux / Applications créatives 🎮

1.0.0+season.winter.2024 → Contenu saisonnier

1.1.0+event.halloween → Fonctionnalités déclenchées par des événements

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

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

⚡ Stratégie de mise à jour de correctifs rapides

1.2.0 → Production actuelle

1.2.1-hotfix.payment → Correction critique

1.2.1+urgent.20240315.1430 → Publié avec horodatage

Pré-version pour les tests, métadonnées pour le suivi de la mise en production

🌍 Stratégie de multi-plateformes

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

1.3.0+android.material3 → Mises à jour de conception Android

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

Même version, métadonnées spécifiques au plateau

🔄 Intégration CI/CD

1.4.0-alpha.1+build.123 → Mise en ligne préalable automatique

1.4.0+deploy.staging.456 → Déploiement de stade

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

Numérotation automatique avec métadonnées de déploiement

💡 Conseils Pro :

Utilisez les métadonnées de construction (+) pour suivre, les horodatages ou les informations cosmétiques qui ne modifient pas la compatibilité
Utilisez les identificateurs de version préalable (-) pour les canaux de développement qui nécessitent une priorité différente des mises à jour
Combinez les deux pour une flexibilité maximale : 1.2.0-beta.1+ui.dark.theme.20240315
Rappelez-vous : Capgo respecte les règles de prééminence de semver, planifiez donc votre stratégie de canal en conséquence

Important : Capgo utilise une versionnement semantique stricte

Contrairement à l'implémentation semver de npm, Capgo suit strictement la spécification SemVer officielle. npm's node-semver a des déviations connues de la spécification, ce qui peut entraîner un comportement inattendu.

Par exemple, npm traite les versions comme 1.0.0-alpha.1 différemment que les exigences de la spécification le requièrent. Voir notre problème signalé et tentative de correction qui n'a jamais été fusionnée.

Versions Sémantiques Valides

1.0.0 ✓ Lancement standard

2.1.3-alpha ✓ Pré-lancement

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

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

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

Versions sémantiques invalides

v1.0.0 ✗ 'v' en tête non autorisé

1.0 ✗ Version de correctif manquante

1.0.0.0 ✗ Trop de parties de version

1.0.0- ✗ Pré-version vide

1.0.0+ ✗ Métadonnées de construction vides

Capgo Comportement de mise à jour

✓ Les mises à jour de correctif sont appliquées automatiquement (1.0.0 → 1.0.1)

✓ Les mises à jour mineures nécessitent une configuration de canal (1.0.0 → 1.1.0)

✗ Mises à jour majeures nécessitent une mise à jour native des magasins d'applications (1.0.0 → 2.0.0)

⚠ Les versions préalables nécessitent une configuration explicite

Cette outil suit la spécification de numérotation sémantique officielle contrairement à l'implémentation de __CAPGO_KEEP_0__. unlike npm's implementation.