Passer à la navigation principale
Logo Capgo

Capgo Testeur de Semver

Vérifiez la compatibilité de la version semantique de vos mises à jour d'application Capacitor

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

Entrez deux versions semantiques pour voir la comparaison

Ce que signifie "Version locale"

La version locale est la version déjà installée sur le dispositif lorsque celui-ci demande au serveur d'actualisation 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 de l'application native d'iOS ou d'Android. N'assumez pas qu'il s'agit de votre package.json version à moins que votre build copie cette valeur dans la configuration 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 configuration obsolète peut signaler la mauvaise version si vous oubliez de l'actualiser 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 installée par les utilisateurs à partir de TestFlight, App Store, Play Store ou de tests internes.

Inconvénients : la modification nécessite une build native et peut différer par plateforme si les paramètres de mise en production divergent.

Ciblez le paquet

Comparez-le avec les versions de paquets distants, les règles de canal semver ou les contraintes d'upload telles que --native-version.

Avantages : empêche d'envoyer du JavaScript qui nécessite des code natifs plus récents vers des binaires d'applications anciennes.

Inconvénients : les règles qui sont trop strictes peuvent bloquer des mises à jour valides jusqu'à ce que les métadonnées du canal ou du paquet soient ajustées.

Pour ce testeur, entrez la version que le dispositif rapporterait comme locale, puis comparez-la avec la version de paquet distant que vous souhaitez Capgo livrer.

Pourquoi Capgo utilise la versionnement Sémantique

Versionnement Sémantique est le standard de versionnement le plus largement adopté dans le développement logiciel. En utilisant semver, Capgo assure la compatibilité et la sécurité lors de la livraison de mises à jour en direct vers vos Capacitor applications.

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

  • Mises à jour de patch (1.0.0 → 1.0.1) : Réparations de bogues, sécurisées pour une application automatique
  • Mises à jour mineures (1.0.0 → 1.1.0): Nouveautés, compatible avec les versions précédentes
  • Mises à jour majeures (1.0.0 → 2.0.0): Changements de rupture, nécessitant une mise à jour de l'appareil native dans les magasins

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

Stratégies 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 méta-données de construction:

🏷️ Méta-données de construction (+) - La couche "Cosmétique"

1.2.0+20240315.142530
Horodatage pour le suivi de déploiement
1.2.0+ui.refresh.dark-mode
Description de mise à jour de l'interface utilisateur pour l'équipe de 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 priorité de version - 1.2.0+anything équivaut à 1.2.0 pour Capgo's logique de mise à jour.

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

1.3.0-beta.1
Chaîne de test bêta
1.3.0-hotfix.payment
Branch de correction urgente
1.3.0-feature.newapi
Branch de test de nouvelle API

Remarque : Les versions préalables 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

Cas d'utilisation de Semver dans le monde réel et stratégies d'équipe

Lancement rapide / Développement rapide

0.1.0 - Première version MVP
0.2.0-beta.1 - Nouvelle fonctionnalité de test
0.2.0+ui.v2 - Métadonnées 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ées 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'audit préalable

Semver strict avec métadonnées 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 hotfix ⚡

1.2.0 → Production actuelle
1.2.1-hotfix.payment → Correction critique de bogues
1.2.1+urgent.20240315.1430 → Sortie 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 iOS spécifiques
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 → Déploiement automatique préalable
1.4.0+deploy.staging.456 → Déploiement de production
1.4.0+prod.final.789 Déploiement automatique avec métadonnées

Conseils :

Utilisez les métadonnées de construction (+) pour suivre, les horodatages ou les informations cosmétiques qui n'affectent pas la compatibilité
  • Utilisez les identifiants de pré-version (-) pour les canaux de développement qui nécessitent une priorité d'actualisation différente
  • Combinez les deux pour une flexibilité maximale :
  • N'oubliez pas : __CAPGO_KEEP_0__ respecte les règles de prééminence de semver, planifiez donc votre stratégie de canal en conséquence 1.2.0-beta.1+ui.dark.theme.20240315
  • Important : Capgo utilise une versionnement semantique stricte

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

Unlike npm's semver implementation, Capgo follows the official SemVer specification strictly. npm's node-semver has known deviations from the spec, which can cause unexpected behavior.

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

Versions Sémantiques Valides

1.0.0 ✓ Sortie standard
2.1.3-alpha ✓ Pré-version
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 ✗ Le 'v' en tête n'est pas autorisé
1.0 ✗ La version de patch manque
1.0.0.0 ✗ Il y a trop de parties de version
1.0.0- ✗ La pré-version est vide
1.0.0+ ✗ La métadonnée de build est vide

Capgo Comportement de Mise à Jour

✓ Les mises à jour de patch 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)
✗ Les mises à jour majeures nécessitent une mise à jour native de l'application dans les magasins (1.0.0 → 2.0.0)
⚠ Les versions de pré-version nécessitent une configuration explicite

Cette outil suit les règles officielles Spécification de versionnement semantique comme npm l'a mis en œuvre.