Capgo Tester de Semver

Vérifiez la compatibilité de la politique de canal par rapport à la base native envoyée sous forme de version_build

Version de la Base Native

La version native envoyée à Capgo sous forme de version_build, depuis la configuration ou les métadonnées de l'application native.

Version Distante

La version de bundle attribuée au canal résolu.

Contexte de l'Application

Plateforme

Construction de Build

Exécution sur Émulateur

Paramètres de Canal

iOS

Autoriser les mises à jour pour les appareils iOS

Android

Autoriser les mises à jour pour les appareils Android

Autoriser la construction de développement

Autoriser les mises à jour pour les constructions de développement

Autoriser les émulateurs

Autoriser les mises à jour pour les appareils émulés

Désactiver la mise à niveau automatique sous native

Empêche la mise à niveau vers une version inférieure lors de l'exécution native code

Désactiver la mise à jour automatique

Principal : bloque les majeures cibles supérieures à la version_build. Permet 1.2.3 -> 1.9.0, bloque 1.2.3 -> 2.0.0.

Entrez deux versions semantiques pour voir la comparaison

Qu'est-ce que "Version native de base"

La version native de base est la version de l'application native envoyée à Capgo lorsque version_build le dispositif demande au serveur d'actualisation un bundle. Dans une application Capacitor, cette valeur peut provenir CapacitorUpdater.version de capacitor.config.*. Si cette configuration n'est pas présente, le plugin se réfère à la version de l'application native provenant 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.

Capgo utilise toujours version_name savoir quel bundle téléchargé est actuellement installé. major, minorpolitiques de canal semver comme patch , et version_build.

Capacitor config

__CAPGO_KEEP_0__ config CapacitorUpdater.version Définir

lorsque vous voulez une version explicite envoyée par l'application. Avantages :

facile à conserver identique dans les builds iOS et Android. Inconvénients :

la config obsolète peut signaler la mauvaise version si vous oubliez de la mettre à jour avant une mise à jour native.

Version de l'application native 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.

Inconvénients : la modification nécessite une compilation native et peut différer d'une plateforme à l'autre si les paramètres de publication divergent.

Ciblage du paquet

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

Avantages : empêche d'envoyer du JavaScript qui nécessite une version native code plus récente aux anciens binaires d'applications.

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

Pour ce testeur, entrez la base native que le dispositif envoie comme version_buildalors comparez-le avec la version distante que vous souhaitez Capgo livrer.

Pourquoi Capgo utilise la versionnement Sémantique

La 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 applications Capacitor.

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ûres à 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 incohérente vers votre application native code, protégeant vos utilisateurs des plantages et garantissant que votre application reste stable.

Stratégies Semver Flexibles : Au-delà de la Versionnement Basique

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

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 métadonnées de construction sont ignorées dans la priorité de version - 1.2.0+anything équivaut à 1.2.0 pour la logique d'actualisation 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

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

🚀 Développement rapide / Lancement de startup

0.1.0 - Première version minimale viable

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

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 → Mise à jour de sécurité avec suivi

2.2.0-rc.1+audit.ready → Candidat de pré-audit

Semver strict avec métadonnées de conformité

🎮 Applications de jeux / 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 correction urgente

1.2.0 → Production actuelle

1.2.1-hotfix.payment → Correction critique d'un bug

1.2.1+urgent.20240315.1430 → Rélease avec horodatage

Pré-version pour les tests, métadonnées pour le suivi de déploiement

Stratégie multi-plateforme 🌍

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 à la plateforme

🔄 Intégration CI/CD

1.4.0-alpha.1+build.123 → Déploiement pré-version automatisé

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

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 le suivi, les horodatages ou les informations cosmétiques qui n'affectent pas la compatibilité
Utilisez les identificateurs de version préliminaire (-) pour les canaux de développement qui nécessitent une priorité d'actualisation différente
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, il faut donc planifier 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 la spécification le requiert. Voir notre incident 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 build

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

Versions Sémantiques Invalides

v1.0.0 ✗ 'v' en début non autorisé

1.0 ✗ Manque de version de patch

1.0.0.0 ✗ Trop de parties de version

1.0.0- ✗ Pré-version vide

1.0.0+ ✗ Métadonnées de build vides

Mise à jour de Capgo

✓ La stratégie mineure permet les modifications de patch dans la même ligne majeure mineure, par exemple 1.0.0 -> 1.0.1

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

✗ La stratégie majeure bloque les bundles cibles avec un majeur supérieur à la base native, par exemple 1.0.0 -> 2.0.0

⚠ La protection de downgrade utilise la prééminence de semver complète, donc stable 1.0.0 est plus récent que 1.0.0-beta.2

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